Hi Brian,
My two cents.
1) This draft is about selective-disclosure. The draft should be
balanced between enclosure and disclosure.
The topic of selective-enclosure should also be addressed.
In particular in OAuth, the claims to be incorporated are usually only
selected with a coarse granularity
and the end-user (as well as the holder) has no clue about which claims
will or will not be incorporated.
2) The draft states:
However, anyone receiving an unencrypted JWT can read all
of the claims.
In OAuth, the claims are considered to be opaque and SHALL not be read
by the holder. Their semantics or content of a JWT can change at any time.
This should be mentioned in the draft.
In the privacy considerations section, another sub-section should be
included about OAuth, i.e. a section "8.3 OAuth".
OAuth considers that the claims included into the JWT are opaque to the
holder (i.e. the Client) when a JWT is used in the context of OAuth.
This means that the holder is unable to verify that the claims that have
been incorporated in the JWT correspond to those that have been requested.
The Issuer is a position to include more claims or different claims from
those that should have been incorporated. This may be a concern for some
end users.
3) About section 8.2 Unlinkability
The text states:
More advanced cryptographic schemes, outside the scope of
this specification, can be used to prevent this type of linkability.
The draft by itself creates the problem since a single JWT is intended
for multiple verifiers.
The linkability problem arises because in particular when the same "sub"
claim is used for two different Verifiers.
The use of the following claims should be avoided (I reuse one of the
examples):
"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
In order to solve the problem, the use of previous claims should be
avoided and a specific "sub" claim should be used for each verifier.
Hence, the concern could be solved using no " advanced cryptographic
schemes " but by defining a new structure in the JWT that would allow
to associate a "sub" claim (as well as other claims) with a specific
Verifier. A change of the SD-JWT Releases structure should be considered.
The use of this draft for end users concerned with some forms of
linkages between verifiers should be deprecated
and this should be mentioned in the Introduction: a single JWT targeted
to a single Verifier solves this concern.
Denis
Hi Hannes,
Though I am yet to officially have my name on the document as a
co-author, you did mention me directly :) And so I'll attempt to
answer or respond to your questions/statements below.
On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig
<hannes.tschofe...@arm.com> wrote:
Hi Daniel, Hi Kristina, Hi Brian,
Hi all,
Reading through draft-ietf-oauth-selective-disclosure-jwt I was
wondering why the document defines new terminology for roles that
already exist in OAuth.
For example:
* Issuer = AS
* Holder = Client
* Verifier = RS
I assume that was done intentionally. What was the rational was.
JWT itself <https://datatracker.ietf.org/doc/rfc7519/> is a product of
this WG (as I'm sure you remember).. While JWT had important
applications in OAuth, it was developed as a more general purpose
token format and has seen widespread usage both in OAuth and beyond.
Similarly, SD-JWT is meant to be a general purpose selective
disclosure mechanism for JWT, which can have applications in OAuth but
is certainly not constrained to OAuth. As such, the terminology in the
draft aims to be generally applicable/meaningful. This is
similar/consistent with JWT/RFC7519, which also does not use terms
like AS, RS, or client.
You write:
“One of the common use cases of a signed JWT is representing a
user's identity“
In classical OAuth this use case should not be common. We bragged
about the fact that you could to delegated authorization without
having to rely on identity information. I think it would help to
expand this statement a bit and explain what the use case is.
A signed JWT representing a user's identity is, in fact, exceedingly
common. Even in classical OAuth the access tokens almost always convey
something about an identity - the resource owner in OAuth parlance.
The sub in introspection
https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the JWT AT
profile https://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show
this in specs, for example. Of course the AT format and content aren't
defined by OAuth itself and are left up to the
implementation/deployment so those optional specs don't tell the whole
story. But every single deployment I've seen has some identity info in
the AT for delegation.
You write:
“ As long as the signed JWT is one-time use, it typically only
contains those claims the user has consented to disclose to a
specific Verifier. However, there is an increasing number of use
cases where a signed JWT is created once and then used a number of
times by the user (the "Holder" of the JWT). In such cases, the
signed JWT needs to contain the superset of all claims the user of
the signed JWT might want to disclose to Verifiers at some point.
The ability to selectively disclose a subset of these claims
depending on the Verifier becomes crucial to ensure minimum
disclosure and prevent Verifiers from obtaining claims irrelevant
for the transaction at hand.“
Using the same access token with multiple resource servers is not
good security practice not only from a privacy point of view but
also from a security point of view.
From reading the introduction I get the impression that you
create your own problem that is subsequently solved in the
document. Since I believe you are too clever to do this, I believe
the document needs to provide more text to explain how this use
case emerged. You mention “verifiable credential” as the “use
case” but it is a technology rather than a use case.
I've reread the introduction (which, in full disclosure, I did not
write) and honestly feel like it does a pretty decent job of
describing the emerging problem space and what the draft aims to
provide. We certainly don't want to leave you or any reader with the
impression that the document invents a not-real problem only to
subsequently solve it. But I'm not getting that impression from
reading it. And I am honestly not sure how to better avoid giving that
impression (other than writing this email, I guess).
/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
