Dear OAuth WG,

while reading through the 01 draft of the Identity Assertion JWT
Authorization Grant (
https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/01/)
and implementing it, we came across some open questions regarding the scope
of the access token for the Resource that we didn't find any answer in the
draft or related specs.

TLDR; The main question that we have is, does the Resource Authorization
Server issue in the access token whatever (scope) is in the ID-JAG?
Below follows a longer elaboration of my thoughts about how to process the
ID-JAG regarding scopes.

The ID-JAG is a grant. A grant is always tied to a scope (implicitly or
explicitly). Shouldn't the scope claim in the ID-JAG be required then? In
that way it becomes clear for the Resource Authorization Server what the
subject consented to (grants access to). According to RFC 7521, section
4.1, (https://datatracker.ietf.org/doc/html/rfc7521#section-4.1), "the
authorization server MUST limit the scope of the issued access token to be
equal to or less than the scope originally granted to the authorized
accessor." If the scope is missing in the grant, the Resource Authorization
Server has to make assumptions about the default scope.
Since the IdP Authorization Server and the Resource Authorization Server
are two different entities in two different trust domains, their policies
may differ. There is a risk that the default scope at the IdP Authorization
Server is not the same as the default scopes at the Resource Authorization
Server, which basically results in the subject consenting to one thing but
the client getting authorized for something different. Therefore, I think,
the scope claim in the ID-JAG should be REQUIRED. The scope of the access
token is the intersection of the scope in the ID-JAG and the requested
scope in the token request. At the end it is at the discretion of the
Resource Authorization Server what scope to include in the access token as
long as it doesn't violate the grant. At least, this is how I think grants
should work.

In my opinion, section 4.4.1 should point to RFC 7521 for validating the
scope claim. The reference to RFC 6749, section 3.3 is not appropriate for
validating the scope claim because it is solely about the scope request
parameter and does not even mention its relation to the authorization
grant. The Resource Authorization Server must not treat the scope claim
like the scope request parameter. While it's ok to ignore a request
parameter, ignoring a grant and the scope of the grant defeats its purpose.
Don't you agree?

I get the feeling that there is quite some duplication of policies in the
IdP Authorization Server and Resource Authorization Server with regard to
scopes. One needs scopes for the grant, the other for issuing access
tokens. Who is responsible for defining the scopes and deciding what ends
up in the access token? In my opinion, it should be the Resource
Authorization Server because it has the authority to grant access to
resources. If that's not the case and the Resource Authorization Server
issues whatever is in the grant, then it's simply an (access) token issuer
for the IdP Authorization Server. What's the purpose of an authorization
server if it doesn't own any policy? Can you elaborate more on the use
cases?

I went down a rabbit hole the more I thought about scopes and I have some
more questions. I may eventually start a new mail thread for those to keep
this conversation focused on how the Resource Authorization Server should
handle the scopes of the ID-JAG.

Best regards,
Judith Kahrer
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to