+1. I think that is correct characterization. Phil
Sent from my phone. On 2013-03-11, at 12:42, Nat Sakimura <sakim...@gmail.com> wrote: > No. I am not confusing scope with audience. > > There is no standard scope. So, the scope has to be either defined by the > resource or the authorization server. > Just stating scope is too vague that you will not able to find out whose > scope it is. > > That is why I wrote that the scope has to be understood in the context of > aud. > Audience is the resource. So what I wrote amounts to be that the scope > expressed in the token is what was defined by the resource and not the > authorization server. > > It could be authorization server's scope, but then there would be a > complication that the resource has to be able to resolve that to its own > scope. Expressing the scope as the audience's scope will free us from this > problem. > > Nat > > =nat via iPhone > > Mar 11, 2013 10:38、Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> > のメッセージ: > >> I would not even want to confuse audience with scope. Maybe in the simplest >> of cases, where there is a one-to-one mapping between scope and audience, >> but in reality the RS could expose multiple APIs at the same endpoint. >> Granted the RS could extract the audience field based on a fully qualified >> scope, but it just seems that claims, scopes, and audiences are each unique >> and should be kept that way. >> >> adam >> >> From: Phil Hunt [mailto:phil.h...@oracle.com] >> Sent: Monday, March 11, 2013 9:25 AM >> To: Nat Sakimura >> Cc: Lewis Adam-CAL022; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> >> One thing that concerns me is that scope is very different from a claim. An >> claim is an assertion provided that may have some level of dispute/quality >> etc. >> >> A scope defines what is request or what has been authorized. It's an >> absolute thing. Therefore it is not a claim. Audience...maybe. >> >> This is why I think scope deserves special attention/discussion in >> authorization assertions and in access tokens. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2013-03-10, at 9:17 PM, Nat Sakimura wrote: >> >> >> So, it is soooo late in the game: I have been completely underwater to even >> read the OAuth mails for about a month and slowly catching up now. >> >> Here is an I-D that I have created partly in response to the RS-AS >> interaction piece that was talked about at IETF 85. >> It does not have 'scope' and has 'claims' instead as it was based on OpenID >> Connect, but it is easy to add, provided that the scopes are to be >> understood as that of the 'aud'. >> >> http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt >> >> Best, >> >> Nat >> >> 2013/3/1 Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> >> Hmmm, I’m not so sure. It depends where we all think OAuth is on its >> trajectory. On one hand, OAuth has already seen an insanely massive amount >> of deployment. On the other hand, RESTful APIs see no sign of slowing down. >> Now I’m not going to go so far as Craig B. and say that everything and >> everyone will be API enabled in the future, but it sure is going to be a >> lot. That being said, one could argue that even with all the OAuth >> implementation we’ve seen, that this is just the infancy of it. Obviously a >> WG profile of a JWT-structured AT could not deprecate other forms >> (unstructured, SAML, etc.) but going forward new developers may choose to >> embrace this, and in fact this could even be the guidance. I agree with >> previous comments that Justin’s introspection draft might be a good place to >> explore this. >> >> adam >> >> From: Brian Campbell [mailto:bcampb...@pingidentity.com] >> Sent: Thursday, February 28, 2013 1:36 PM >> To: Lewis Adam-CAL022 >> Cc: John Bradley; oauth@ietf.org WG >> >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> >> >> I do agree that a WG profile of a JWT-structured access token could lend >> itself to interoperability and ultimately be a useful thing. But you are >> right that there already are many implementations out there in the wild >> (heck, I've written one myself) and that might make it difficult to >> standardize on something. >> >> Because of that, and many other reasons, I don't want to try and add that to >> existing assertion drafts. >> >> >> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 >> <adam.le...@motorolasolutions.com> wrote: >> Hi Brian, a few thoughts from somebody outside of the WG … >> >> As a newcomer to OAuth last year, I was initially confused by the titles. >> It was confusing because we have SAML bearer *assertions* and JWT bearer >> *tokens* … and as John just (begrudgingly) stated in this thread, the JWT is >> being used as an assertion in this profile (and in OIDC). I think it will >> be difficult to find a good name for these profiles since they do two >> entirely different things (e.g. define a new grant type and define a new >> method of client authentication). One could argue that as long as the WG is >> at it, then why not add a third section to the JWT profile, which talks >> about usage of JWT-structured bearer access tokens: it would not be any less >> related than the other two focuses of the doc. Then the document could be >> called something simple like “profiles of JWT usage in OAuth” or something >> like that. >> >> On one hand, it is probably naïve to think that an access token can be >> standardized in a profile given how many have already been released into the >> wild, but on the other hand, a WG profile of a JWT-structured access token >> could lend itself to interoperability, where AS implementations can >> advertise conformance to the profile and who knows … maybe the RS’s of the >> future will be good with this. >> >> adam >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Brian Campbell >> Sent: Thursday, February 28, 2013 1:03 PM >> To: John Bradley >> Cc: oauth@ietf.org WG >> >> Subject: Re: [OAUTH-WG] JWT - scope claim missing >> >> I'm not sure anyone really "picked" the titles for the bearer token >> profiles. They just kind of evolved. And evolved in funny ways especially >> when client authn to the AS was added. >> >> You won't hear me argue that the titles are "good" and this is not the first >> time there's been confusion about what they actually do. They define new >> grant types and new client authentication methods. They *do not* define an >> access token format or anything else about access tokens. JWT and SAML could >> be used for that but that's not what these drafts do. >> >> Suggestions for better title(s) would be more than welcome. >> >> Here's what they are now: >> >> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 >> draft-ietf-oauth-saml2-bearer >> >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> draft-ietf-oauth-jwt-bearer >> >> Assertion Framework for OAuth 2.0 >> draft-ietf-oauth-assertions >> >> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <ve7...@ve7jtb.com> wrote: >> Yes the title likely adds to the confusion given that the bearer tokens are >> not access tokens. >> >> Things as separate from OAuth as the Firefox browerID spec use JWS signed >> JWTs. >> >> The bearer token profiles for OAuth 2 are for OAuth2. >> >> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth >> specific. >> >> A JWT is: >> JSON Web Token (JWT) A string representing a set of claims as a JSON >> object that is encoded in a JWS or JWE, enabling the claims to be >> digitally signed or MACed and/or encrypted. >> >> So OAuth or other profiles may define claims to go in a JWT, but the JWT >> needs to itself only define the claims necessary for security processing. >> >> John B. >> PS that was a soft ball If you hadn't responded I would have been >> disappointed. I din't pick the title for the bearer token profiles. >> >> >> On 2013-02-28, at 10:12 AM, Phil Hunt <phil.h...@oracle.com> wrote: >> >> >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> >> >> Note the title says "for OAuth2" >> >> Sorry. Couldn't resist. >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 9:40, John Bradley <ve7...@ve7jtb.com> wrote: >> >> JWT is an assertion( I am probably going to regret using that word). >> >> It is used in openID connect for id_tokens, it is used in OAuth for >> Assertion grant types and authentication of the client to the token endpoint. >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04 >> >> >> >> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> >> >> Dosen't define JWT's use for access tokens for the RS. >> >> Bottom line JWT is for more than access tokens. >> >> John B. >> >> On 2013-02-28, at 9:28 AM, Phil Hunt <phil.h...@oracle.com> wrote: >> >> >> Are you saying jwt is not an access token type? >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 8:58, John Bradley <ve7...@ve7jtb.com> wrote: >> >> Yes, defining scope in JWT is the wrong place. JWT needs to stick to the >> security claims needed to process JWT. >> >> I also don't know how far you get requiring a specific authorization format >> for JWT, some AS will wan to use a opaque reference, some might want to use >> a user claim or role claim, others may use scopes, combining scopes and >> claims is also possible. >> >> Right now it is up to a AS RS pair to agree on how to communicate >> authorization. I don't want MAC to be more restrictive than bearer when it >> comes to authorization between AS and RS. >> >> Hannes wanted to know why JWT didn't define scope. The simple answer is >> that it is out of scope for JWT itself. It might be defined in a OAuth >> access token profile for JWT but it should not be specific to MAC. >> >> John B. >> On 2013-02-28, at 8:44 AM, Brian Campbell <bcampb...@pingidentity.com> wrote: >> >> >> I think John's point was more that scope is something rather specific to an >> OAuth access token and, while JWT is can be used to represent an access >> token, it's not the only application of JWT. The 'standard' claims in JWT >> are those that are believed (right or wrong) to be widely applicable across >> different applications of JWT. One could argue about it but scope is >> probably not one of those. >> >> It would probably make sense to try and build a profile of JWT specifically >> for OAuth access tokens (though I suspect there are some turtles and dragons >> in there), which might be the appropriate place to define/register a scope >> claim. >> >> >> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.h...@oracle.com> wrote: >> Are you advocating TWO systems? That seems like a bad choice. >> >> I would rather fix scope than go to a two system approach. >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 8:17, John Bradley <ve7...@ve7jtb.com> wrote: >> >> > While scope is one method that a AS could communicate authorization to a >> > RS, it is not the only or perhaps even the most likely one. >> > Using scope requires a relatively tight binding between the RS and AS, >> > UMA uses a different mechanism that describes finer grained operations. >> > The AS may include roles, user, or other more abstract claims that the the >> > client may (god help them) pass on to EXCML for processing. >> > >> > While having a scopes claim is possible, like any other claim it is not >> > part of the JWT core security processing claims, and needs to be defined >> > by extension. >> > >> > John B. >> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> >> > wrote: >> > >> >> Hi Mike, >> >> >> >> when I worked on the MAC specification I noticed that the JWT does not >> >> have a claim for the scope. I believe that this would be needed to allow >> >> the resource server to verify whether the scope the authorization server >> >> authorized is indeed what the client is asking for. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> 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 >> _______________________________________________ >> 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 >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
