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> 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> > 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> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> 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 > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
