SD-JWT VC Chaining / Delegation?
c2bo opened this issue · comments
I've been getting increasing amounts of questions about delegation / chaining with sd-jwts (and mdoc). Especially delegation seems to be a topic that people are starting to wonder about with cases like a person acting on behalf of another person in certain scopes (e.g., tax consultant accessing a system on your behalf).
My naive thought was that this could be done similarly to how the x5c header parameter currently works: Introduce a new header parameter that contains an sd-jwt (including key binding jwt and relevant disclosures) where the chained sd-jwt is used to establish trust (via the original issuer) and resolve the key (confirmation claim) for signature validation. For implementations, this should not add too much effort as it would just be a recursive call to verify the contained sd-jwt vc.
I am not entirely sure it makes sense to bring in the additional complexity (and privacy concerns) but on the other hand I do see benefit in supporting some kind of credential chaining / delegation mechanism within the credential format itself. Do you think that this is something worth discussing and would this be the right spec to do so?
good point, since the delegation in a SSI model must be perfomed by the end-user and not centralized in a credential issuer, the idea that came to my mind is to:
- define a credential type for this specific purpose
- define a data model for this specific purpose
- issue a self-issued token using SIOPv2 using a personal wallet
- encapsulate in this token two credential presentation (with the disclosure minimized for the purpose of the delegation):
- the one of the delegator with the aud set to the final RP and the delegated subject
- the one of the delegated with the aud set to the final RP and the delegator subject
- the token that encapsulate these two presented credentials with disclosure must be signed using the private key related to the public key to the delegator credential, contained in this token (providing the proof of possession)
- the delegator provides this token to the delegated
the RP that received this token from the delegated, in a VP_Token during a presentation, recognize the type and then the corresponding data model.
Extracts the two VC, evaluates the trust with both their issuers, evaluates the pop of the delegator, evaluates the pop of the delegator in the presentation, then authenticates/grants the delegated.
how these tokens can be exchanges should be further defined. In my assumoption cannot exist delegation for any RP, each delegation must be configured with a specific RP or a set of RPs (aud). the chained approach is nested using attribute and cryptografic bindinds.
to be continued ... :-)
I agree with @peppelinux that this is not an SD-JWT VC spec question, it is a credential type question. IMO, this is out of scope of this spec.
I would concur that this is beyond the scope of this spec.
I generally agree (which is also why I was unsure if I should raise this issue here), but that poses the question: Where would we propose a structure for this? Imho it would make sense to propose a general approach that is shared at least to some degree between different credential types.
@c2bo a brand new draft should born explaining a "shared credential", where the holder of this shared credential presents the enveloped credential(s) is a brand new type of credential specifically born for this use case
I share to you my Car key credential (shortlived), you present this to my Car and drive it untill the credential is valid (unexpired/revoked).
this - definitively - exalts concepts of sharing vs. presentation and also delegated presentation.
@c2bo a brand new draft should born explaining a "shared credential", where the holder of this shared credential presents the enveloped credential(s) is a brand new type of credential specifically born for this use case
I share to you my Car key credential (shortlived), you present this to my Car and drive it untill the credential is valid (unexpired/revoked).
this - definitively - exalts concepts of sharing vs. presentation and also delegated presentation.
I would expect those things to be very ecosystem (EUDIW) or even domain-specific (car vendors). However, SD-JWT VC is extensible by design and can include any sort of claims and even another PID credential as a claim (if needed), so I believe this use case is supported in general but out-of-scope of this specification.
@c2bo @peppelinux Marking this as pending close for one week and then close if no activity.
I agree that this is likely going to be somewhat ecosystem specific, but I do believe one place to create an "example" / best practice could still help though. I agree that this draft is probably not the right place though -> let's figure out where this would fit.
I agree that this is likely going to be somewhat ecosystem specific, but I do believe one place to create an "example" / best practice could still help though. I agree that this draft is probably not the right place though -> let's figure out where this would fit.
Best practices depend on ecosystem-specific requirements. For instance, in some countries you won't have (Q)EEAs that are bound to a public key, or won't have an identifier in the PID that can be used to bind the (Q)EEAs to the PID, and and and.
There are many different ways how this can be solved. Simple and more complex. The following is no guidance but should show there are many different options and they depend heavily on ecosystem capabilities such as the presence of a PID, usage policy of PIDs (one-time vs multipe-times, ...) etc, and the anticipated user experience.
For example, the delegation could be a SD-JWT VC (a (Q)EAA) issued by the delegator that contains:
- claims about the delegator.
- claims about the delegate or the PID key of the delegate to establish some form of linking later.
- In case the SD-JWT VC was signed by the PID key of the delegator, then it would probably also contain the PID of the delegator with the claims to allow the verifier to do claims matching at presentation time. In that case, you probably don't need the claims about the delegate explicitly.
- signature of the delegator (produced by the key bound to the delegator's PID, or by a QES or AES authorized by the delegator potentially by presenting their PID)
- if the signature was produced by the PID, it would probably even include the PID of the delegator, or QES/AES cert.
Instead of binding this to claims about the delegate, you could also include the key of the PID of the delegate instead (or some other key the delegate controls) which will require that the delegator has that information.
Perhaps a simpler example would be, the SD-JWT VC would be issued by the receiving party, e.g., delivery website, let's call it Foo, in case somebody else wants to get a delivery on behalf of the delegator. In that case, a flow could be,
- delegator goes to Foo website and authenticates using their PID
- delegator enters information about the delegate, e.g., firstname, lastname
- Foo issues an SD-JWT VC with no cryptographic binding, delegator receives it and stores in their wallet.
- Delegator sends SD-JWT VC to delegate and delegate stores the SD-JWT VC in their wallet as well.
- Delegate presents their PID and the SD-JWT VC (with no KB-JWT) to Foo
- Foo verifies linking based on claim matching
In the above example, Foo could be also the wallet of the delegator, and instead of claims, one could issue the SD-JWT VC to a specific key provided by the delegate.
I can think of many many variations of this. Without understanding requirements of the specific use case better, I'm not sure if we could come up with best practices and include such an example.
@c2bo is there a list of use cases with more specific requirements?
I am not aware of a somewhat complete list of use-cases. The main use-cases that I have seen mentioned and been asked about (and also ones that we are most interested in) goes into the direction of Power of Attorney. Acting on behalf of another entity via some sort of signed credential/document.
Should we close this issue here and figure out a better place to have this discussion?
Closing now since it is out of scope.