Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Hans Zandbelt <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]>
> 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=
>> [e-mail]> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu