Hi Rifaat,
I would like to mention the excellent paper from Oliver Terbu, as lead
author:
https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/identifier-binding.pdf
This paper explains what the problems are (but not what the solutions are).
Let me also recall the Alice and Bob collusion attack :
https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/
Unless incorporating into the VP one or more attributes that allow to
unambiguously identify the legitimate holder
(which may not respect the ISO 29100 principle of "collection
limitation"), there are two problems currently unsolved
when using VCs in the off-line mode:
*
make sure that a VP (Verifiable Presentation) presented by Alice
is not based on a VC issued to Bob.
*
make sure that two VPs presented by Alice are indeed based on
two VCs issued to Alice by two different Issuers.
There exists at least one solution in the on-line mode (i.e. a VC is
specifically generated upon the request of its legitimate holder)
but originally, VCs have been designed to be used in an off-line mode.
Since the chairs would "like to see more feedback and discussion on the
list and during the coming IETF meeting
before considering adoption", I copy and paste my earlier comment sent
on the list:
Note: Since then, VCDM, i.e. Verifiable Credentials Data Model has moved
to version 2.0.
https://www.w3.org/TR/vc-data-model-2.0/
However, Version 2.0 still contains EXAMPLE 25 (A verifiable
presentation that supports CL Signatures)
which is vulnerable to the ABC attack (unless incorporating into the VP
one or more attributes that allow
to unambiguously identify the legitimate holder).
============================================================================================
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
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
