Hi Oliver,
On may 27, 2023, I sent an email to you, Lief and on the list and
(unless I missed it) I have not seen a reply to it.
A response would be appreciated. I copy and paste below the content of
that email.
Denis
Note : A "presentation of an SD-JWT VC" is different from a "Verifiable
Presentation".
==============================================================================================================
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
Dear all,
Thank you all for your feedback so far.
I would like to share an update on the SD-JWT VC draft that Daniel
Fett and I have been working on.
Here is the link to the updated IETF data tracker:
https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
Please note that we had to make a change to the IETF data tracker name.
I am excited about the opportunity to present the draft specification
in person at IETF 117.
Thank you,
Oliver
On Thu, Jun 8, 2023 at 12:15 PM Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com> wrote:
Thank you all for your feedback on this document.
The chairs would like to make it clear that this is a call for
feedback at this stage.
This is *NOT* a call for adoption, because we think it is too
early for that. We would like to see more feedback and discussion
on the list and during the coming IETF meeting before considering
adoption.
Regards,
Rifaat & Hannes
On Wed, Jun 7, 2023 at 10:02 PM Michael Jones
<michael_b_jo...@hotmail.com> wrote:
Here’s some feedback based on a full read of the draft…
You will eventually be asked to reference RFC 8174, like is
done at
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-16.html#name-conventions-and-terminology.
You might as well do it sooner than later.
To follow the IETF draft naming conventions, you need to
include the intended working group name as the third component
of the draft name. So for instance, this draft should
probably be renamed to draft-terbu-oauth-sd-jwt-vc or
draft-terbu-jose-sd-jwt-vc.
In
https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2
(Registered JWT Claims), I’d specify that the “iss” value must
be a URL using the “https” scheme. That way the
.well-known/jwt-issuer metadata will always be retrievable.
In
https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2
(Registered JWT Claims), why must the “sub” value be a URI?
Are we not interested in use cases where the “sub” references,
for example, an OAuth client, where the Client ID value is a
UUID (a string)? StringOrURI seems like a better choice.
In
https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-5.1
(JWT Issuer Metadata Request), I question whether “If the
|iss| value contains a path component, any terminating
|/| MUST be removed before inserting |/.well-known/| and the
well-known URI suffix between the host component and the path
component.” is always the right choice. Yes, I know that
that’s what it takes to conform to RFC 5785 and I wrote
similar text at
https://www.rfc-editor.org/rfc/rfc8414#section-5 , but
practically, the permissions on servers may not be
administered in a way that allows tenants to write to this
location. (Yes, I plan to continue the conversation with Mark
Nottingham about allowing .well-known in locations other than
the root.)
I especially like this section
https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#name-jwt-issuer-metadata-4
(JWT Issuer Metadata)!
Hope you find this review useful…
-- Mike
*From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Oliver
Terbu
*Sent:* Saturday, May 27, 2023 2:56 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Request for Feedback on "SD-JWT VC"
Draft Specification
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.
oliver.te...@spruceid.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
