Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification

[Denis <[e-mail]>]

Hi Oliver,

I browsed through the document which does not seem to comply with VCDM, 
i.e. Verifiable Credentials Data Model v1.1,
W3C Recommendation 03 March 2022. The latest published version is 
available at: https://www.w3.org/TR/vc-data-model/

VCDM states:

Holders of verifiable credentials can generate *verifiable 
presentations* and then share these verifiable presentations with verifiers
         to prove they possess verifiable credentials with certain 
characteristics.

In the draft, Figure 1 should indicate that usually Verifiable 
Presentations are generated by the holder and then presented to the 
Verifier.

In the draft, section 1.2 states:

        While JWT-based credentials enable selective disclosure, i.e., 
the ability for a Holder to disclose only a subset of the contained claims,
        in an Identity Provider ecosystem by issuing new JWTs to the 
Verifier for every presentation, *this approach does not work in the 
three-party-model*.

VCDM offers the ability for a Holder to disclose only a subset of the 
contained claims.

Figure 1 is incorrect and does not comply with section 3.3 of VCDM which 
states:

        The expression of a subset of one's persona is called a 
verifiable presentation.

The current draft is only using the wording "verifiable credentials" and 
never the wording "verifiable presentations".
It would seem natural to speak of "verifiable presentations". If 
verifiable presentations are deliberately out of the scope, a rational 
should be given.

It is questionable why this work should not be undertaken by the 
Verifiable Credentials W3C Working Group.
Have contacts been established with this W3C Working Group ?

*Additional comments on this proposal
*
Section 5.10 of VCDM states:

Verifiable credentials are intended as a means of reliably *identifying* 
subjects. While it is recognized that Role Based Access Controls (RBACs)
        and Attribute Based Access Controls (ABACs) rely on this 
identification as a means of authorizing subjects to access resources, 
this specification
        does not provide a *complete *solution for RBAC or ABAC. 
Authorization is not an appropriate use for this specification without 
an accompanying
        authorization framework.

Since a verifiable presentation may contain only a subset of the 
attributes of a user, this specification already provides a *partial 
*solution for ABAC.

The OAuth 2.0 *authorization framework* is a protocol that allows a user 
to grant a third-party web site or application access to the user's 
protected resources,
without necessarily revealing their long-term credentials or even their 
identity.

Intensive cryptographic computations are usually needed by a holder to 
create a Verifiable Presentation. These computations should be reduced 
to the strict minimum.

As an example, if using a Verifiable Presentation a user needs to prove 
that he is over 18, once he has proven this property, it does not need 
to provide it again and again,
since if he is over 18 today, he will still be over 18 for the rest of 
his life.

It other words, a user should only provide this Verifiable Presentation 
once and for a daily usage of a web site authenticate using other (and 
lighter) means .

When logging for the first time to a web site, a user may wish or be 
invited to register to that web site, so that the next accesses can be 
performed using a user identifier
(e.g. a pseudonym) and authentication data (e.g. a password or a private 
key).

The scope, as currently proposed, does not seem to be adequate. Section 
2 of the draft states:

This specification defines:

  * Data model and media types for Verifiable Credentials based on SD-JWTs.
  * Validation and processing rules for Verifiers and Holders.

If this draft proposal is taken as a WG draft, the articulation between 
user authentication and user authorisation should be addressed.

A side question is the following : will this draft be dealing with 
identification and/or authorization ?

Denis


> Likewise!
>
> Skickat från min iPhone
>
>> 27 maj 2023 kl. 01:12 skrev Giuseppe De Marco <[e-mail]>:
>>
>> 
>> Hi,
>>
>> I support sd-jwt-vc with the will to contribute to its evolution and 
>> use it in the wallet solutions under development
>>
>> Il ven 26 mag 2023, 16:57 Oliver Terbu <[e-mail]> ha 
>> scritto:
>>
>>     Dear all,
>>
>>     I hope this email finds you well. I am writing to introduce
>>     "SD-JWT-based Verifiable Credentials with JSON payloads” (SD-JWT VC):
>>
>>     https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/
>>
>>     This proposal builds upon the existing SD-JWT specification by
>>     the OAuth WG and aims to address certain gaps and provide
>>     specific guidance for utilizing SD-JWT in the context of
>>     Verifiable Credentials. For example, while SD-JWT defines how to
>>     implement selective disclosure in JWTs (an important building
>>     block in many Verifiable Credential use cases), it is not
>>     opinionated about the specific JWT Claim Sets in the payload to
>>     represent Verifiable Credentials and used with HB-JWT.
>>
>>     As you may be aware, the SD-JWT specification has already been
>>     adopted by the OAuth WG and has gained significant traction
>>     within the industry. However, the SD-JWT specification does not
>>     provide explicit guidance on using SD-JWT for Verifiable Credentials.
>>
>>     The eIDAS 2.0 Architecture Reference Framework (ARF) has
>>     expressed a keen interest in utilizing SD-JWT for Verifiable
>>     Credentials, and SD-JWT VC became one of the two core credential
>>     formats of the European Digital Wallet (EUDIW):
>>
>>     https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework
>>
>>     Verifiable Credentials play a crucial role in enhancing digital
>>     trust and enabling secure identity interactions in various
>>     domains. To ensure the seamless integration of SD-JWT into the
>>     eIDAS ARF and similar initiatives, it is essential to address the
>>     existing gaps in the SD-JWT specification specifically relevant
>>     to Verifiable Credentials.
>>
>>     As a general-purpose format, SD-JWT itself is not the right place
>>     to define these kinds of guidelines. The SD-JWT VC draft proposes
>>     to fill these gaps by defining additional requirements,
>>     clarifying ambiguities, and providing concrete guidelines for
>>     utilizing SD-JWT in the context of Verifiable Credentials. Since
>>     SD-JWT VC and SD-JWT are closely related, we propose to develop
>>     this specification in the OAuth working group.
>>
>>     Your support and endorsement of this proposal would significantly
>>     contribute to the advancement of Verifiable Credentials.
>>
>>     If you have any questions or require additional information
>>     regarding the "SD-JWT VC" specification or its potential impact,
>>     please do not hesitate to reach out.
>>     I’m looking forward to your feedback!
>>
>>     Oliver Terbu
>>
>>     -- 
>>     Director of Identity Standards, Spruce Systems, Inc.
>>     [e-mail]
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth