To be fair, I think it was Phil who first conflated the things :) I just picked up the ball and ran with it. But you are right, I did kind of hijack the thread which was originally about if a scope claim should be defined in draft-ietf-oauth-json-web-token. I'd say no but I can see how an argument could be made the other way.
On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell <bcampb...@pingidentity.com > wrote: > 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)<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06> 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
