Hi Hannes,
Sorry for this late response. The SPICE BoF (and other activities) kept
me quite busy.
Hi Denis,
OAuth defines 4 roles, see Section 1.1 of RFC 6749.
A RO is a role supported by a (human) user.
In the three party model there is likely a human behind the holder as
well.
You can map the OAuth terms to the VC terms, if you like, as follows:
* Issuer: Authorization Server
* Holder: Client
* Verifier: Relying Party
The mapping you propose does not work. Section 2.1 from RFC 7636 states:
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server
(i.e., ability to maintain the confidentiality of their client
credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server
with restricted access to the client credentials), or capable of
secure client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used
by the resource owner, such as an installed native application or a
web browser-based application), and incapable
of secure client authentication via any other means.
If a Holder were to be a client, would it be a private client or a
public client ? The response is: none of them.
In W3C VCDM 2.0, the Holder is defined as:
holder
A role an entity might perform by possessing one or more verifiable
credentials and generating verifiable presentations from them.
Example holders include students, employees, and customers.
Students, employees or customers SHOULD NOT be confused with applications.
TEEs, Trusted Applications, etc. are implementation specific details.
You can use them in OAuth, and other protocols as well.
TEEs, Trusted Applications, etc. are NOT implementation details. They
are fundamental components in the design, but are not considered
in OAuth 2.0 and neither in the OAuth 2.1 draft. TAs are slightly
similar to confidential clients but are fundamentally different
since they must support additional security properties.
There is a need to consider the existence of TAs (Trusted Applications)
which are separate from the RichOS (e.g., Android or iOS)
thanks to the existence of a TEE (Trusted Execution Environment). A TA
needs to be downloaded into a TEE, hence both TEE Issuers
and TA Issuers also need to be part of the model.
The model has three *roles*, i.e., Holder, Issuer and Verifier and at
least supports the following additional *entities*:
TA, TA Issuer, TEE, TEE Issuer, RichOs, RichOS Issuer and the user agent.
user agent
software and hardware used by a natural person to interact with
the World Wide Web
Note: a user agent should not be confused with a client as defined in
RFC 6947:
client
An *application* making protected resource requests on behalf of the
* resource owner* and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
draft-ietf-oauth-sd-jwt-vc-00 is unable to support the three *roles*
(i.e., Holder, Issuer and Verifier) and does not distinguish the
previous additional *entities*
Considering "client implemented on a secure server with restricted
access to the client credentials" is outdated. We are now all using
smart phones.
Smart phones need to be considered, which means that digital identity
wallets also need to be considered.
As an example, Trusted APs are supported on iPhone beginning with iOS
16, but do not work on IPad. More information is available here:
https://developer.apple.com/documentation/passkit/wallet/requesting_identity_data_from_a_wallet_pass
Trusted APs do not currently exist on desktops or laptops.
Regarding the question: "What the IETF should do (or not do) in this
area ?"
The answer is: We are working in the IETF on these topics already, see
Web Authorization Protocol (oauth) (ietf.org)
<https://datatracker.ietf.org/wg/oauth/documents/>.
There are exactly 48 documents listed in the link you provided.
Most of them are unrelated to the topic of "OAuth and JWT/VC documents",
but two of them are attempting to make a bridge between VCs and JWTs:
* SD-JWT-based Verifiable Credentials (SD-JWT VC)
draft-ietf-oauth-sd-jwt-vc-00
* Selective Disclosure for JWTs (SD-JWT)
draft-ietf-oauth-selective-disclosure-jwt-05
The example in section 4.3 from draft-ietf-oauth-sd-jwt-vc-00 is rather
innovative, since this draft (and its companion draft) attempts to define
age limit attributes such as : Claim is_over_21 or Claim is_over_65.
{
"type": "IdentityCredential",
"given_name": "John",
"family_name": "Doe",
"email": "john...@example.com",
"phone_number": "+1-202-555-0101",
"address": {
"street_address": "123 Main St",
"locality": "Anytown",
"region": "Anystate",
"country": "US"
},
"birthdate": "1940-01-01",
"is_over_18": true,
"is_over_21": true,
"is_over_65": true
}
Some observations:
1) The last items should rather be:
"is_over_18": null,
"is_over_21": null,
"is_over_65": null
null describes the absence of a value.
A JWT shall never contain a line like "is_over_21": false.
2) Since age limits are most often country dependent and it would not be
appropriate to define a set of Claims "is over_XX" with XX between 7 and 77
and the same set for Claims "is under_XX" between 7 and 77. Instead of
registering to IANA around 140 claims, it would be simpler to register
to IANA
only two claims: "age_over" and "age_under" able to contain one or more
age values.
This is possible by ignoring the following sentence placed in section 4
of JWT (RFC 7519):
"The Claim Names within a JWT Claims Set MUST be unique".
... which means using a JSON structure _that will NOT be conformant to
RFC 7519 (JWT)_.
The "privacy considerations" section of draft-ietf-oauth-sd-jwt-vc-00 is
nearly empty. :-(
Since RFC 7519 indicates that all of the claims are OPTIONAL, is there a
set of claims that SHALL be present in the VC issued by the Issuer to
the Holder ?
Same question for a VP presented by an Holder to a Verifier ?
Even if no claim is been disclosed, the use of a JWT does not allow to
support the Unlinkability property between verifiers.
Both this section and the Introduction should indicate that this
solution *by design* does not permit to support the unlinkability
property between verifiers.
Note that the W3C data model, which is rather flexible, allows to
support the unlinkability property between verifiers.
Using a JWT does not only mean that its data structure shall be
compliant to RFC 7519 but also to its processing requirements,
i.e. to 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.
draft-ietf-oauth-sd-jwt-vc-00 is currently unable to conform to section
7 from RFC 7519 (JWT).
The OAuth 2.1 Framework states:
"Access tokens are credentials used to access protected
resources. An access token is a string representing an authorization
issued to the client.
The string is considered opaque to the client, even if it has
a structure".
This is consistent with the OAuth 2.0 Framework, but a client CANNOT
consider a JWT-VC to be *opaque* when it receives it from the Issuer.
Nor the OAuth 2.0 Framework or the OAuth 2.1 Framework is able to
support the draft-ietf-oauth-sd-jwt-vc-00.
Regarding the question: "The protocols between an holder and a
verifier are rather different from those defined in OAuth, since in
many cases they support Zero-Knowledge proofs (ZKPs).
The answer is: No, not necessarily. That's what the whole SD-JWT is
about.
A zero-knowledge proof is a method involving one or more exchanges
between a prover and a verifier where the prover is able to convince the
verifier
that a statement is true, without revealing to the verifier any
additional information beyond that knowledge.
draft-ietf-oauth-sd-jwt-vc-00 supports selective disclosure, but reveals
more information about the prover than the disclosed claims.
It discloses information that allows different verifiers to link the
proofs they receive. By design, draft-ietf-oauth-sd-jwt-vc-00 is unable
to support the Unlinkability property between verifiers. ZKP cannot be
supported. That's what the whole SD-JWT *VC* is about.
Denis
Ciao
Hannes
*Von:*OAuth <oauth-boun...@ietf.org> *Im Auftrag von *Denis
*Gesendet:* Samstag, 9. September 2023 15:44
*An:* Roman Danyliw <r...@cert.org>
*Cc:* oauth <oauth@ietf.org>
*Betreff:* Re: [OAUTH-WG] OAuth and JWT/VC documents
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 STEELE *Chief Technology Officer www.transmute.industries
<http://www.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
