Historically, the OAuth WG has been using a model including five
components: the user, the Client, the AS, the RO and the RS.
The model applicable in the context of the "three part model (issuer,
holder, verifier)" is rather different since there is no AS, nor RO.
An AS should not be confused with an Issuer. An Issuer has no
relationship with a verifier.
In the "three part model", a Credential is issued by an Issuer to an
holder who may then derive himself from it one or more Verifiable
Presentations
without any call-back to the Issuer. The holder may then present to a RS
one or more Verifiable Presentations derived from Credentials issued
by the same or different Issuers. It is implicit that the "three part
model" shall support selective disclosure of the holder's attributes.
The "three part model (issuer, holder, verifier)" involves more entities
/ components: the user, the TEE (Trusted Execution Environment)
supported by the smart phone or tablet manufacturer, Trusted
Applications (TAs) placed into the TEE, the providers of these Trusted
Applications (TAs)
and the RichOS supported by the smart phone or tablet. Security and
privacy concerns can only be achieved while considering the whole chain.
The protocols between an holder and a verifier are rather different from
those defined din OAuth, since in many cases they support Zero-Knowledge
proofs (ZKPs).
Before designing an architecture, it is important to raise the following
questions:
* Is it desirable to support linkability between verifiers and/or
unlinkability between verifiers ?
* How to bind a Verifiable Presentation to its legitimate holder while
also supporting the unlinkability property between verifiers ?
IMO, bridging the architectural narrative used in the core OAuth
framework (AS, RS, RO) and three part model (issuer, holder, verifier)
is not desirable.
This would add confusion. Extending the OAuth charter to address the
"three part model" is not desirable.
Some committees and foundations are already addressing this topic, e.g.,
W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform
(for the TEE).
The key question is: what the IETF should do (/or not do)/ in this area ?/
///
A BoF should be opened to continue this discussion.
Denis
Thanks for kicking off the conversation!
Inline:
On Fri, Sep 8, 2023 at 2: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?
There are building blocks that "look like VC" but are actually vanilla
JWT / relevant outside the 3 party model. I would recommend keeping
them at OAuth (status list cwt is an example of this IMO).
It's possible that a document at OAuth recognizing the data model
elements of the 3 party model (iss, sub, cnf, kid, etc) might help
enable documents outside of OAuth to better defer to OAuth for "moving
tokens, or leveraging successful protocols"... this could help reduce
the data model reinvention everywhere else, and it could drive the
common understanding of registered claim names to be
interpreted consistently across JWT / CWT (and their SD friends).
** For whatever that work might be, how should the OAuth charter
evolve to support the work?
I don't know, but I am happy to help : )
One thing that seems worth unpacking is why DCP at OIDF is leaving the
OIDC part behind (paraphrasing, kristina probably has a better take):
https://openid.net/wg/digital-credentials-protocols/
Are there things DCP might need from OAuth WG, how might the charter
align to that 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?
I think so? but it depends on the comment above.
Personally I would like to see the OAuth WG tackle this head on,
especially because of the wallet / client / subject / holder
confusion.... Starting with the people we are here to serve seems like
a safe way to progress through the technical sugar (which I love).
OS
Thanks,
Roman, Hannes, and Rifaat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
ORIE STEELEChief Technology Officerwww.transmute.industries
<https://transmute.industries>
_______________________________________________
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
