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<mailto:oliver.te...@spruceid.com>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
