:)
The more I think about 'sub' the more I don't think is should mean
"user". What about an IoT device? To me it feels like 'sub' should be
what 7519 states, the subject or principal of the token. In some cases,
that is quite legitimately the "client" or "machine". Changing that
semantic seems bad. If a developer needs to know whether this JWT is
about a "human" or not, that's something else entirely and could have
it's own claim.
On 4/4/19 11:38 AM, Hans Zandbelt wrote:
agreed but it (i.e. "sub") also brings us back to where we started
Hans.
On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell
<bcampbell=40pingidentity....@dmarc.ietf.org
<mailto:40pingidentity....@dmarc.ietf.org>> wrote:
The same is true for most of the other main claims too - iss, exp,
aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.
On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>>
wrote:
Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the
definition of `aud` which should be the reference and this
document can provide additional specifics for the given
application.
On Thu, Apr 4, 2019 at 8:07 AM George Fletcher
<gffletch=40aol....@dmarc.ietf.org
<mailto:40aol....@dmarc.ietf.org>> wrote:
Another comment...
aud REQUIRED - as defined in section 2 of [OpenID.Core
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
See
Section 3
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
for indications on how an authorization server should
determine the value of aud depending on the request. [Note:
some
vendors seem to rely on resource aliases. If we believe
this to
be a valuable feature, here's some proposed language: The aud
claim MAY include a list of individual resource indicators
if they
are all aliases referring to the same requested resource
known by
the authorization server. ]
I don't think OpenID.Core Section 3 is the correct
reference for determining the 'aud' value. The issue here
is that the 'aud' of the id_token is the recipient of the
id_token (i.e. the client). However, for access_tokens the
'aud' value should be the resource service that will
receive the access_token. There is no existing guidance
for this and we should provide such guidance as this is
"kind of new" for OAuth2 (from an explicit specification
perspective).
Also, there is the concept of 'azp' from the id_token
which amounts to "who's allowed to present this token"
which might be interesting from the case where one entity
obtains the token, and gives it to another entity to
present. Not sure if we want to include this concept or not.
Finally, I think we may need some best practice around how
the concept of audience and resource should be managed.
For instance...
If the request does not include a resource parameter, the
authorization server MUST use in the aud claim a default
resource
indicator. If a scope parameter is present in the request, the
authorization server SHOULD use it to infer the value of the
default
resource indicator to be used in the aud claim.
I think for most implementations this would amount to...
define an audience that covers all the resource services
where the access token can be returned and set that as the
audience (e.g. urn:x-mydomain:apis). Which is perfectly
legal but maybe not in the spirit of the spec:) I am
receiving feedback from developers that binding access
tokens narrowly to the resource where they will be
presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS
infrastructure.
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for
OAuth 2.0 access tokens. You can find it in
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll
be presenting remotely). I look forward for your comments!
Here's just a bit of backstory, in case you are
interested in how this doc came to be. The trajectory it
followed is somewhat unusual.
* Despite OAuth2 not requiring any specific format for
ATs, through the years I have come across multiple
proprietary solution using JWT for their access
token. The intent and scenarios addressed by those
solutions are mostly the same across vendors, but the
syntax and interpretations in the implementations are
different enough to prevent developers from reusing
code and skills when moving from product to product.
* I asked several individuals from key products and
services to share with me concrete examples of their
JWT access tokens (THANK YOU Dominick Baier
(IdentityServer), Brian Campbell (PingIdentity),
Daniel Dobalian (Microsoft), Karl Guinness (Okta) for
the tokens and explanations!).
I studied and compared all those instances,
identifying commonalities and differences.
* I put together a presentation summarizing my findings
and suggesting a rough interoperable profile (slides:
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
<https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
) - got early feedback from Filip Skokan on it. Thx
Filip!
* The presentation was followed up by 1.5 hours of
unconference discussion, which was incredibly
valuable to get tight-loop feedback and incorporate
new ideas. John Bradley, Brian Campbell Vladimir
Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes
Tschofenig were all there and contributed generously
to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the
discussion and didn't get credited in the draft, my
apologies: please send me a note and I'll make things
right at the next update.
* On my flight back I did my best to incorporate all
the ideas and feedback in a draft, which will be
discussed at IETF104 tomorrow. Rifaat, Hannes and
above all Brian were all super helpful in negotiating
the mysterious syntax of the RFC format and
submission process.
I was blown away by the availability, involvement and
willingness to invest time to get things right that
everyone demonstrated in the process. This is an amazing
community.
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
