Grant Management use prohibits SSO, prompt=none, etc
Issue #380
resolved
If the parameter is not present and the AS always issues grant ids or the AS optionally issues grant ids (see (#server_metadata)) and the client requires grant ids (see (#client_metadata)), the AS MUST create a new grant and return the respective grant id in the token response.
If
- there’s already an active OP session established with the RP being checked in in the past
- mechanism for recalling previous persisted grants
then there’s no reason to return a new grant. At most i think we should mandate a return of the grant id in token response, but otherwise don’t always require a new grant.
There was an authorization request control parameter in the previous drafts that controlled whether the client wants a fresh grant or not IIRC, i wouldn’t mind keeping that parameter around if necessary.
Comments (21)
-
-
reporter
The point is that the client may have already cleared its session records (or is a stateless client) and is not aware of the previous grant_id, so it cannot send one in.
So in cases where the OP may have the capability to recall existing grants it would be against the requirements to recall then any time this draft is supported. Please don’t dictate that behaviour, otherwise this is impacting usability of this draft for general oauth use.
-
Would you assume such a client to utilize grant management at all? Otherwise, we could give it the ability to turn grant management on/off using a client registration parameter.
-
reporter
Client-based policy would indeed help alleviate my worries. That being said I think an explicit grant_management_mode combined with an OP default_grant_management_mode policy would be better suited.
-
What would be the benefit? As you pointed out the previously defined grant_management_mode would have needed an additional default behavior. We removed it (https://bitbucket.org/openid/fapi/pull-requests/216) in order to simplify the spec while being able to fulfil the requirements we are aware of.
The client-based policy is in the spec (with the grant_id_required client registration metadata) and is easier to use in my opinion.
-
reporter
The client-based policy is in the spec (with the grant_id_required client registration metadata) and is easier to use in my opinion.
Is it? Because it does not work always. See below, i think it may depend on how that language is parsed.
If the parameter is not present and the AS always issues grant ids
or the AS optionally issues grant ids (see (#server_metadata)) and the client requires grant ids (see (#client_metadata))
then the AS MUST create a new grant and return the respective grant id in the token response.
If the authorization endpoint parameter is not present but the AS always issues grant ids then the client metadata does not seem to do anything in regards to the AS always having to issue a NEW grant when i read it like described above.
Is it meant to be?
If the parameter is not present
and the AS always issues grant ids or the AS optionally issues grant ids (see (#server_metadata)) and the client requires grant ids (see (#client_metadata))
then the AS MUST create a new grant and return the respective grant id in the token response.
That’s also not fine.
If the intention is that if the client omits grant_id but is set with grant_id_required then always issue a new grant instead of being able to recall one then the description (JSON boolean requesting the AS to provide grant ids in the token response. If omitted, the default value is no grant ids required.) does not match this intention.
Bottom line i think we need to describe better the way for a client to signal that it asks for a new grant while leaving the option for the AS to always return one, albeit a pre-existing one, otherwise.
-
f the intention is that if the client omits grant_id but is set with grant_id_required then always issue a new grant instead of being able to recall one then the description (JSON boolean requesting the AS to provide grant ids in the token response. If omitted, the default value is no grant ids required.) does not match this intention.
You are right. The definition of the client metadata parameter needs to be revised.
OLD
grant_id_required OPTIONAL. JSON boolean requesting the AS to provide grant ids in the token response. If omitted, the default value is no grant ids required.
NEW
grant_id_required OPTIONAL. JSON boolean requesting the AS to provide grant ids in the token response and to create a new grant id if none is provided in the authorization request. If omitted, the default value is no grant ids required.
-
reporter
And if I merely want ensure to get a grant_id in the response from an AS that is set to
grant_id_supported=optional? The client will also force new grants to be created, from its POV as a side effect. -
That’s a different story.
The draft currently does not aim at providing a client with a pre-existing grant id in case no grant id is present in the authorization request. The client is supposed to fully manage its grant ids and make sure it always specifies the grant id it wants to be updated/considered in a subsequent authorization request.
We could change this. But what would be a compelling use case?
I’m asking since in that case it would be up to the AS to identify grants and define the scope of grants. No actual control from the client’s perspective.
-
reporter
The draft currently does not aim at providing a client with a pre-existing grant id in case no grant id is present in the authorization request.
That’s not the same as AS already having a grant for the user/client combination and the client just wanting to make sure it gets a grant_id back. As pointed out in the draft, Grant Management API revoke operation gives the client assurance that said grant_id will not be further used as pre-existing grant when invoked, as opposed to token revocation (e.g. when passing a refresh token) where this is left unspecified.
Ergo, as a general use mechanism we should support a case where
grant_id_supported=optionaland client merely wants to make sure a grant_id is returned, without affecting the policy on the AS about using pre-existing grants. -
Not sure this is even the right place to say this but I think more work is needed before it can be stated that the aforementioned PR simplified the spec. I’m having a hell of a hard time reasoning about the expected outcome of all the potential combinations of the presence of grant_id parameter and the two different AS metadata parameters and one client metadata parameter. The logic here is really hard to follow:
If the parameter is present and the AS supports grant updates (see (#server_metadata)), the AS will assign all permissions as consented by the user in the actual request to the respective grant. If the parameter is not present and the AS always issues grant ids or the AS optionally issues grant ids (see (#server_metadata)) and the client requires grant ids (see (#client_metadata)), the AS MUST create a new grant and return the respective grant id in the token response. Otherwise, the AS MUST NOT return a grant id in the token response.
-
PR #247 is my attempt to clarify the language
-
-
assigned issue to
Stuart Low
-
assigned issue to
-
Intent to add use case for prompt-none involving
updatewith == permissions acting as a potential token recovery mechanism. -
@Filip Skokan I think the original issue is gone with the re-introduction of the grant_management_action. Would you agree? Can we close the ticket?
-
reporter
@Torsten Lodderstedt is https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md the latest state i can refer to?
-
Latest edits:https://bitbucket.org/openid/fapi/pull-requests/266
-
reporter
@Dima Postnikov @Torsten Lodderstedt it would seem that the language currently on master branch + PR #266 does not prohibit the use of SSO anymore, so thats a concern gone.
How do you feel about adding a language about defaults? Again, I’m thinking of a case where Grant Management is retrofitted to a general non-FAPI AS. From observing the existing servers I would suggest that a default would be that
grant_management_actionisupdatewith the AS selecting the appropriategrant_idautomatically e.g. from its pre-existing stored records or the current end-user session. That however means thatgrant_idis not REQUIRED in that defaulted-to case.Additional suggestion I have is to introduce AS and RS metadata
require_grant_management_actionthat would indicate that thegrant_management_actionauthorization parameter MUST be provided. -
re default: The currently specified behavior requires the AS to return a grant id if a grant management action is specified in the authorization request OR it supports query/revoke via the API. If the client does not specify a grant id in the authorization request, it is up to the AS to identify/create a grant and also decide on the way for combining existing and requested permissions. We think this is a sensible default, since it allows implementers to continue to use their pre-existing logic. We also think an interoperable solution requires the client to request a certain management action.
-
For require metadata, PR created: https://bitbucket.org/openid/fapi/pull-requests/274/introduce-require-metadata-item
-
- changed status to resolved
PR merged
- Log in to comment
The idea is to allow the client to explicitly request creation of a new (independent) grant if it requires so. If the client already obtained a grant_id in a previous authorization process, it is supposed to pass this grant_id to subsequent authorization processes it wants to operate with this grant_id (and the respective underlying grant).
I would assume in the scenario you described, the client would be in possession of a grant id and could use it.
We removed the additional parameter in order to simplify the design after checking we could fulfil requirements in CDR and others. Instead of the additional grant_management_mode parameter, the AS is now supposed to create new grants if there is no grant id passed in the authorization request.