Indicating support for VCs (SIOP)
Issue #1205
resolved
Verifiable Credentials are a new way of expressing credentials, that has not been previously used with OpenID Connect, with emerging need to do so. In those use-cases it would be important to ensure that both RP and OP(SIOP) support VCs.
Suggest adding vc_supported boolean parameter in the registration to indicate such support.
Comments (17)
-
-
reporter
good point.
to make it even more generic, while indicating specific formats, suggest “credential_formats_supported”: [an array of supported formats]
Regarding the formats, Claim Format Designations in DIF Presentation Exchange specification is a good starting point IMHO.
Valid values would include jwt, jwt_vc, jwt_vp, ldp_vc, ldp_vp, and ldp.
-
VC is always shared with a RP via a VP.
It would make sense to indicate:
- supported VP format (it can be JSON, JSON-LD, it could be XML (w3c vc is not limited to json/json-ld), …)
- supported VP proofs (signatures) – similar to
id_token_signing_alg_values_supported
Note that the client doesn’t have control over the VC format/signature type (that is embedded in the VP).
-
sounds ok - i i believe that to embed any of these in a SIOP message, it will need to be encoded. I had proposed (somewhere) that we use jose encoding. That would imply the sig was encoded separately from the body - i don’t see any issue with that myself.
As a second issue, in a PE (presentation exchange) it was my understanding that the client spec’d all the parms?
But if a PE is involved there would be no VP in a SIOP? - i guess i need to see a use case.
-
reporter
@Alen,
For supported signatures there is
credential_formats_supportedregistration metadata in the draft (jwt, jwt_vp, ldp, ldp_vp). We probably might not be the only supported VP format. In your use-case, would it be better to separate supported credential formats from credential signatures? Note that we want to support claims not only in VC/VP format. -
reporter
VC is always shared with a RP via a VP
I agree. We may want to state this explicitly, since theoretically it is possible to share only VC or VP without a VC (derived claims).
-
Jeremie from Ping is working on an embedding doc.
Not clear to me if it belongs in this sub group, but it is likely to address this. I certainly want something like this to be available across docs.
As i look at the issue we should have encodings that allow any format VC to be embedded in any SIOP or related request. The interesting question is whether jose can do that as written (it seems to me) or if we might need to add a field to the header to handle some of the weird crypto. Does anybody have a list of formats and weird crypto?
-
Account Deactivated
The draft I’m working on is here: https://hackmd.io/@quartzjer/JWS_Sets
It’s still a work-in-progress but I’ve started circulating it some. The best place is likely an internet draft once there’s some more feedback and validation.
The goal isn’t to wrap or encompass something like LD Proofs, but instead to provide a means of supporting BBS+ and similar privacy-tooling signature types consistent with the JOSE stack.
-
I supporting moving this forward as a topic. Not sure where it belongs, i suppose the the siop doc is as good as anywhere.
-
I would like to bring this back up for resolution.
Postulate: There needs to be an interoperable Credential provider - not clear that is w/i scope of this effort, but it must exist. Among other formats it would be able to provide compliant Verifiable Credentials.
Postulate: There is no use case where a verifiable credential would ever be required in an ODIC or SIOP flow. These need to be converted to Verifiable Presentations which are expected to be included in a SIOP flow. The exact format for that element is under discussion. (see alan’s point above.)
Note: There is no reason that a CP and SIOP are not co-hosted, but that should not imply that a SIOP flow contains a VC.
-
Account Deactivated
I think it’s helpful to be even more explicit about terminology here, or at least it helps me
Tom, in your postulates when you say “Verifiable Credential” I believe you’re talking specifically about the object that is issued from a provider to a holder (about a subject). That object only exists in that private context during an issuance action.
Whenever any relying party or verifier is involved it is always a Verifiable Presentation, being presented by a holder with the consent of the subject. That object is likely to be materially different than the verifiable credential from above, having been through a process of selective disclosure and any cryptographic privacy protection.
My confusion happens when all of these flows are together called “Verifiable Credentials” and it’s unfortunate we don’t have an equivalent action-noun like “presentation” to use to easily distinguish the issuance side.
All that said, I agree with your first postulate that an issuance spec must exist. While I haven’t read the latest draft yet, I believe that’s the intended scope of this work?
On your second postulate, I agree that issuance doesn’t make sense for SIOP to provide but as a holder it will be an initiator/recipient of an issuance flow which may have SIOP implications.
I do think it’s worth discussing an OIDC relationship to credential issuance, but in my mind it could be as simple as a requested/granted “vc” scope that enables the client’s access token to interact with the provider’s issuance service.
-
“Regarding the formats, Claim Format Designations in DIF Presentation Exchange specification is a good starting point IMHO.
Valid values would include jwt, jwt_vc, jwt_vp, ldp_vc, ldp_vp, and ldp.”
^ why are we not just leveraging Presentation Exchange objects/definitions to support these things? I want to push back strongly against redoing/duplicating work that is already defined and adopted widely across the VC ecosystem.
-
Part of the reason that the PX is not sufficient is that you deliberately skipped any consideration of user consent. You told me “it belongs at a higher level”. Well, here we are at a higher level.
-
@Kristina Yasuda , if we want to support any claims, not limited to VC/VP data models, then it would make sense to split the media type, content type, signature, encryption. Of course, it comes at a cost.
Whenever an RP supports a limited combination of the media type and content type (and signature, encryption), the proposal below makes sense:
<media type>_<content type> as suggested: (jwt_vc, jwt_vp, ldp_vc, ldp_vp)
Pros: clear, short
Cons: growing number of combinationsIn case there are many combinations, we could group them, like:
<media type>
<content type>
like: { “typ“: “jwt“, “cty“:[ “vp“, “vc“] }or if all combinations are supported: { “typ“: [“jwt“, “json-ld“], “cty“:[ “vp“, “vc“] }
pros: media type and content type easier to register by IANA (most are already registered)
cons: larger in size, should this mean that the RP supports all combinations?This would be only for
vc_supported– what about a name vc_type_supported?OP and RP need also to agree upon the signing and encryption algorithms (like in the case of dynamic client registration https://openid.net/specs/openid-connect-registration-1_0.html) – the combination of proposed signatures and cryptographic suites can be quite extensive.
What do you think?
-
I’m going to step over Tom’s hazy comment about 'user consent', because this thread about formats/algs/suites, not user consent (which PE does already includes description info hooks for, but I digress). Instead, I will note this format/alg/suite issue is a solved problem with an accepted syntax most of the DID community is already circling around, which has been integrated into multiple stack formulations already: https://identity.foundation/presentation-exchange/#:~:text=The Presentation Definition MAY include a format property
-
I know
PE is a very nice and elaborated proposal. Great work!How you solve the problem of a potentially large number of combinations? Or is this a false assumption (I guess we’ll meet jwt, json-ld, XML, the VC specs (see the quote below) also mention some other less used formats, like YAML, CBOR – never seen credentials in these formats though)?
Also the comment of Kristina: Note that we want to support claims not only in VC/VP format.
This section specifies how the data model is realized in JSON-LD and plain JSON. Although syntactic mappings are provided for only these two syntaxes, applications and services can use any other data representation syntax (such as XML, YAML, or CBOR) that is capable of expressing the data model." (https://www.w3.org/TR/vc-data-model/#syntaxes)
-
- changed status to resolved
This is being addressed in OpenID Connect for Verifiable Presentations.
- Log in to comment
Since the VC spec is a data model i am not suree that any boolean parameter of the sort vc_supported is helpful in any way i can imagine. It is specific formats that might be interesting. I would make more sense to have an optional element
“vc_cred”:[bunches of types accepted]
Also - it is really unclear that VCs would ever be sent to RPs. wouldn’t those be VPs?