Closed OIDF-automation closed 9 months ago
+1
I think the question is
sub
Claim of an issued VCand I think we need change iss to be the the user identifier (same logic as Self-Issued ID Token) and make a separate parameter for client_id if we need it.
in the spec, here, we have 2 examples
{
"alg": "ES256",
"kid":"did:example:ebfeb1f712ebc6f1c276e12ec21/keys/1"
}.
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"iat": 1659145924,
"nonce": "tZignsnFbp"
}
In this one, a) we need to provide guidance what goes into sub Claim of an issued VC; and b) the current design does not account for relative DID URLs where kid
is only #keys-1, because actual DID to which the fragment gets appended has to be in the JWT body (maybe time to get back to PR #293 )
{
"alg": "ES256",
"x5c":[<key certificate + certificate chain for attestation>]
}.
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"iat": 1659145924,
"nonce": "tZignsnFbp"
}
In this one, a) we need to provide guidance what goes into sub Claim of an issued VC - I think it should be JWK thumbprint URI
discussed at Nov-10-2022 SIOP call - people asked to elaborate, which I did (cc Oliver)
I’d also say it should be a JWK Thumbprint but the W3C VC spec says that the credentialSubject.id must be a URI. So, we might consider using JWK Thumbprint URIs (RFC 9278).
this is for a proof of possession of a DID, not a VC, but for namespacing purpose, should still be a URI?
very much related to #223.
I think we should define an optional sub
parameter in a proof to put user's identifier
consolidating the discussion to #223
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1720
Original Reporter: KristinaYasuda
should be jwk thumbprint uri