Spec was ambiguous when there was more grant type. The translation seperates the token issuance from the scopes being asked for. Gate tuples and scope tuples.
In case of authorization_code asking for an access token, but many requests come back with a refresh token also.
Spec now has a seperate tuple for each gate. access token to pass, but refresh token can fail now
Now possible to have a policy decision for varying refresh token length based on the request
Karl: Grants are independant of the token type. You can downscope a token to grants issued to the client. Grant is a first class object, rather than the token.
Omri: These are related. When a user consents, a grant is recorded, and a token is issued.
Karl: Why is the resolution not grants coming back?
Omri: It is - there is a gate tuple for each token and scope - each with a decision.
AlexB: The AS records the grant - assume they work as token minting when grant exists. Issuing the grant leads to issuing the token.
Karl: You can down scope tokens. The user can do something different to the downscoped token. Trying to find the boundary between minting token and grant issuing.
Omri: This spec reads on the token endpoint not the authorize endpoint.
AlexB: Isn't that too late - if the grant happened before
Karl: You want to serialize the errors on the front channel
Omri: Dave Hyland brought up the same question. Happy to expand the scope to cover authorize endpoint.
Karl: Key is its a PDP for an AS - each endpoint is to be covered. Omri asked to have issue filed.
What the client is told on the deny
More detail on unhappy path.
If the gate tuple fails for one of them (multple audience) - then fail the whole request
With token exchange there are two tuples.
Handle a PDP avalibailty issue with a retry error
Step-up
If we expand the scope - this needs rethinking.
AlexB: This argues moving it to the authorize endpoint
Right now, this adds a security consideration for the policy
ID token gate has no resource
The audience should be the issuance target, but client_id for the id token
Karl: Why not muddle the resource indicator.
An ID token has a user info scope. The spec is silent if an adidtional scope is added to the gate.
Namespcae conflict
There is a convention now
For a gate tuple there is a convention of issue:<action_type>:<grant_type>. Scope was verbaitam.
No way to distinguish the two outside of the prefix.
Fix: have the resource.type to discriminate
AlexO: Should we prefix them? Easy to pick out of logs
AlexB: Having standardized types - every PDP has differnet model. Why should we enforce IANA defined types?
Omri: Normalization is what drives interopabiltiy.