Since this is the last call, I thought I bring up some of thoughts / concerns. Some of them have been discussed before.
*client_id vs sub* I am still not entirely happy with the “re-purposing” of the claim types based on flow. If the intention is, that sub expresses the entity against which the resource will do authorisation (and that might be a client or a user) - I get it (and maybe it should be stated like that) - but this thinking reminds me of the old AD days where there was no distinction between user and service accounts (something that has been fixed IIRC in Windows Server 2012 R2). All other OAuth specs make a very clear distinction between users and client. Furthermore it says "Authorization servers should prevent scenarios where clients can affect the value of the sub claim in ways that could confuse resource servers.” If we keep that dual semantics of the sub claim - it must be clearly stated, that subject ID and client ID are now in the same collision domain. So when an AS / OP creates them, they need to be unique across user ids and client ids. Maybe it should be also explicitly mentioned that sub has a different semantic here as in OIDC - even though a majority of the software built today will use them together. *audience claim* I am not fully clear why aud is required. OAuth itself does not have a notion of an audience (in the JWT sense) - they have scopes (which is very similar). But in simple scenarios where resources don’t exist, you'd need to make up an audience just to fulfil this requirement. And in many case this will be either static or just repeat the scope values. What’s the value of that? If the concept of resources are used, I absolutely agree that aud should be used too. But I wouldn’t make it required. *iat vs nbf* What’s the rationale for using iat instead of nbf. Aren’t most JWT libraries (including e.g. the .NET one) looking for nbf by default? *General* This spec feels somehow in between a profile and a BCP. On one hand you define some claims and their semantics (good) - on the other hand there is some prescriptive guidance and maybe over-specification. My concern is, that in the end no-one will fully comply with it, because it doesn’t work one way or the other for them. I know we just went though the discussion to make certain claims required as opposed to optional - but maybe less is more. Tbh - the most valuable part of the doc to me is the definition of the “at+jwt” typ. For the rest I’d rather like to see just some standard claims and IF they are used, which semantics they have. cheers ——— Dominick Baier On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.i...@gmail.com) wrote: Hi all, This is a second working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens". Here is the document: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06 Please send your comments to the OAuth mailing list by April 29, 2020. Regards, Rifaat & 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
