# Daniel and Kristina

1. Presentation Interop Profile
- when can we implement updated 4VP/SIOPv2 profiles?
- Updated 4VP spec is so much better...
- Can we implement StatusList2020?
- Test suites

2. SD-JWT
- Define SD-JWT-VC
- https://github.com/w3c/vc-data-model/issues/908
- define how presentation exchange looks like. Verifier specifies which claim names within a specific credential type. but verifier

3. Issuance
- Issuer metadata format
- Discovery
- Hardcoding does not scale
- Display
- doing .well-known might be complicated
- Propose passing metadata_uri as a middle ground
- Issuance Pre-Authorized Code Flow
- DID team to spin out a separate token endpoint that understands pre-authorized code (need to think more)

4. Other
- Namespace collision of credential_types/scopes
- in presentation verifier specifies type and issuer
- in issuance contract contains issuer specific authorization endpoint (multi-tenant)

DG: Schema being an URI and namespacing.
Followup on status list version in teh profile.
How do we know that we're talking to ests and use our client ID
Question about the metadata URL. If we go the well-known route, where does the 1st part of the url comes from? We currently pull from 2 different well-known, using the DID in case of did:web and the other one is for linked domain. They can be different urls. So I'm wondring where this well-known would be hosted.
mDL

-What would the scope in the metadata would look like. And do we need the hardcoded one if it can be discovered dynamically. Question for DG: do we need more than 1 scope (to make graph calls)
-Wht is in the issue rmetadata and at what level is it? What about the callback url.
-linked domain for issuance
-Add P256 curve (cloud managed HSM don't always support ed25519)
Credential Refresh