Hi Brian,
The main questions raised by Roman were:
What's the body of work around SD/JWT/VC that should be done and how
much work will that be?
What needs to be done first?
The topic is about SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). It is not
about SD-JWT (draft-ietf-oauth-selective-disclosure-jwt).
At a first glance, using JWTs within SD-JWT-VC seems fine, since none of
the claims defined in RFC7519 are intended to be mandatory to use or
implement.
However, compliance to RFC 7519 (JWT) means compliance with all the
content of the document, i.e., including its processing requirements
defined in section 7. "Creating and Validating JWTs". None of these two
sections (i.e., 7.1 and 7.2) allows to create and verify a JWT-VC
as intended in draft-ietf-oauth-sd-jwt-vc.
Are JWTs adequate to be used in the context of a "three *roles* model"
(i.e., Holder, Issuer and Verifier) ?
Both OAuth 2.0 and OAuth 2.1 consider that a JWT is "considered opaque
to the client, even if it has a structure".
This consideration cannot apply to SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc).
The "three roles model" should be usable using smartphones supporting
Digital Identity Wallets. Unfortunately, this is not the case
with draft-ietf-oauth-sd-jwt-vc.
The three roles model should consider (at least) seven other *entities*:
TA, TA Issuer, TEE, TEE Issuer, RichOs, RichOS Issuer and the user agent.
Neither the OAuth 2.0 Framework, nor the OAuth 2.1 Framework, considers
these seven entities.
Below is an answer to the second question raised by Roman:
*What needs to be done first? **
*
1) A Framework, usable in a smartphone environment, needs first to
be defined with its own vocabulary and its own data flows.
Let us call it something like: "The Credentials Framework 1.0".
Then after the trust relationships between the various roles and
entities need to be defined.
In order to follow both a privacy-by-design and a
security-by-design approach, a model including the ten entities (and
maybe more)
should first be defined with a description of the sequencing of
the flows and of the interactions between its entities.
Then after, both a "Security considerations" section and a
"Privacy considerations" section should be written to highlight
which security and privacy properties are intended (and are not
intended) to be supported.
2) The W3C VCDM 2.0 model should be analysed in order to identify
which aspects should be retained and which other aspects should be
discarded,
with a rational for each aspect. This implicit means that the
full W3C VCDM document will not necessarily be endorsed. One of the
results of this analysis
would be to identify which syntaxes and semantics would be
candidate to be used for VC, and for VPs, with pros and cons.
Copyright issues might need
to be addressed between the W3C and the IETF and I am fully
ignorant on that aspect.
3) Schemas for VCs supported by a given Issuer should then be
defined, so that a Holder may request a Credential corresponding to
a selected profile.
4) All the data flows, starting from the data flow between a
pre-Holder and an Issuer, will need to be considered.
Much more than a single RFC will be needed. Both the W3C and the OpenID
Foundation (OIDF) have already paved the beginning of this path.
Placing such a work under the umbrella of the OAuth WG is questionable
since it would likely create a confusion with the OAuth 2.0 and OAuth
2.1 Frameworks
and this is one of the topics currently discussed in the SPICE BoF.
Would a Creds WG be more appropriate ?
Denis
Hi Roman,
I'm going to dodge some of the bigger picture questions but wanted to
give a bit of historical context/justification for the
draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG.
JWT <https://datatracker.ietf.org/doc/rfc7519/> itself was a product
of OAuth WG yet was intentionally developed as a general-purpose token
format with no direct dependency or relation to RFC6749
<https://datatracker.ietf.org/doc/html/rfc6749>. JWT certainly had
useful applications in OAuth/RFC6749 but it wasn't limited to such.
JWT has seen widespread usage in a variety of applications and other
standards, which is arguably a testament to the intent and nature of
that development.
SD-JWT
<https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/>
is basically just a selective disclosure mechanism for JWT. It builds
on and leverages the established and familiar constructs of JWT. It is
similarly intended to be a general-purpose specification. Given that
broad intent and SD-JWT's relationship to JWT, with JWT's heritage of
being developed in the OAuth WG, it seemed only natural and
appropriate that SD-JWT follow suit and find its "home" for
development in the OAuth WG too. SD-JWT has been an active work item
of the WG for about a year and has matured nicely in that environment.
I'm (maybe naively) hoping that the work is closer to the end of its
time in WG than it is to the beginning.
On Fri, Sep 8, 2023 at 1:08 PM Roman Danyliw <r...@cert.org> wrote:
Hi!
We've observed growing energy around JWT, selective disclosure and
VC related topics in the WG in recent meetings. We spent almost
all of the third OAuth meeting at IETF 117 on related topics. The
initial SD-JWT (draft-ietf-oauth-selective-disclosure-jwt) has
been followed up with SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc).
There is also work like draft-looker-oauth-jwt-cwt-status-list
being proposed.
As promised at IETF 117, we would like to start a conversation
about the direction the WG would like to take at a strategic level
rather than continuing to deal this topic in one document
increments of additional scope.
** What's the body of work around SD/JWT/VC that should be done
and how much work will that be? What needs to be done first?
What unknown about the direction and needed tasks?
** For whatever that work might be, how should the OAuth charter
evolve to support the work?
** Is there work to be done around bridging the architectural
narrative used in the core OAuth framework/RFC6749 (AS, RS, RO)
and three part model (issuer, holder, verifier) used in
draft-ietf-oauth-selective-disclosure-jwt?
Thanks,
Roman, Hannes, and Rifaat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly
prohibited. If you have received this communication in error, please
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./
_______________________________________________
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
