[Openid-specs-fapi] Grant Management Draft

Torsten Lodderstedt torsten at lodderstedt.net
Sat Mar 21 11:36:30 UTC 2020


Hi Dave,

thanks for reviewing the draft. 

> On 18. Mar 2020, at 17:57, Dave Tonge <dave.tonge at momentumft.co.uk> wrote:
> 
> Hi Torsten
> 
> I've reviewed the draft and here are some comments:
> 
> >  Should the AS always return the grant_id if the client once asked for it?
> Instinctively I would say no, it would place an extra burden on the AS for not much benefit
> 
> >  Should the AS rotate grant ids for privacy reasons?
> I would say no. I think it is useful to think of these grants as restful resources, and rotating ids will cause confusion.

we discussed the privacy implications of grant ids extensively among the authors. The grant_id, by definition, is bound to a certain user id. So seeing the same grant id on different devices directly tells the client that it is interacting with the same user. We came up with the conclusion we should prevent recognition of “the same user” using grant ids.  

We removed the “get” grant management mode, so the client will only get access to a grant id if it requested its creation (grant management mode “create”) and it is the client that needs to specify the grant id in subsequent transactions. If the client is able to use the same grant id on another device, this means it is able to relate a certain user using its own user management, which is appropriate.

> 
> > API authorization
> This is a tricky one, I feel the current situation is too broad and too specific.

Can you please explain why? 

> I don't think the spec should specify the scope value for the endpoints.
> I would suggest that either:
> 1. the endpoints are assumed to be at the AS and are protected through standard client auth
> 2. security for the endpoints is not specified

How would you envision to implement a client management API client in an interoperable manner? Client authentication alone does not give you an access token with the required privileges to access the API. Letting the security of the endpoint unspecified is, in my opinion, even worse. Mapping this to OpenID Connect would have meant, the endpoint security of the user info endpoint was left unspecified. 

The proposal in the draft facilitates interoperability. The client can use any suitable grant type to obtain a grant, I assume it would be one of the client credential(ish) grant types. The client asks for well defined scope values  and gets an access token that it uses to query or delete grants. 

> 
> > Revoke Grant
> I think we need to talk about the relationship with https://tools.ietf.org/html/rfc7009 and what the AS should do with any tokens associated with a grant.

Good point - here is the text I added

Note: Token revocation as defined in [@RFC7009] differentiates from grant revocation as defined in this specification in that token revocation is not required to cause the revocation of the underlying grant. It is at the discretion of the AS to retain a grant in case of token revocation and allow the client to re-connect to this grant through a subsequent authorization request. This decoupling may improve user experience in case the client just wanted to discard the token as a credential.

> 
> > grant_id potentially could be shared by different client_id belonging to the same entity.
> This may well be desirable. Perhaps we should spec how to do this using sector identifiers?

Sector identifiers is just one way to do it. 

Here is my proposal:

Note: a client (as logical entity) MAY use multiple client ids to deliver its service across different platforms, e.g. apps for iOS and Android and a Web App. It is RECOMMENDED that the AS supports sharing of grants among client ids belonging to the same client. Sector identifier URIs as defined in [@!OpenID.Registration] is one option to group client ids under single administrative control.

> 
> Thanks so much to all those who have worked on the document so far.

You are welcome. Thanks for your feedback!

I have create a PR (https://bitbucket.org/openid/fapi/pull-requests/158) containing the changes I did based on your feedback. Please review and comment or approve. 

best regards,
Torsten. 

> 
> Dave
> 
> 
> On Sat, 14 Mar 2020 at 22:32, Torsten Lodderstedt via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> Hi Filip,
> 
>> Am 14.03.2020 um 18:49 schrieb Filip Skokan <panva.ip at gmail.com>:
>> 
>> 
>> Hi Torsten,
>> 
>> I just used the text from PKCE but I’m not bound to it. May I ask you to propose text?
>> 
>> how's this? 
>> 
>> The `grant_id` value MUST be generated by the authorization server and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) of at least xxx bits.
> 
> thanks. What would be a sensible choice for xxx?
> 
>> 
>> Yes, I did. I'm personally in favour of the grant id since the whole OAuth 2 framework is built on ids and corresponding endpoints. Introducing a new pattern in this extension deviates from the established patterns. I see the advantage in terms of flexibility but is it worth a different pattern? I think it would have been the right decision back when refresh tokens were designed as part of RFC6749.
>> 
>> It's not necessarily a new pattern, dynamic client registration's `registration_client_uri` uses the same pattern. 
>> 
>> Moreover, I think it is possible for an AS to support the request parameters without exposing the grant management API. The parameters by itself are a useful feature even if the deployment does not have a need to let clients query the status or even delete grants. And lastly, a URI would increase the authorization request size.
>> 
>> That is good enough an argument for id only. I guess the only remaining thing i dislike is the fact the client has to know to append `/${grantId}` to the end of a discovered endpoint. I'd much rather the id be always part of the payload, but alas GET and DELETE don't support body payloads... :(
> 
> I don’t feel appending the id is a big deal.
> 
> best regards,
> Torsten.
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>> On Sat, 14 Mar 2020 at 18:07, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
>> Hi Filip, 
>> 
>> > On 11. Mar 2020, at 14:01, Filip Skokan <panva.ip at gmail.com> wrote:
>> > 
>> > Hello Torsten,
>> > 
>> > Thank you for putting this together, here's my feedback:
>> > 
>> > I think a standalone resource (string or array of strings) (when used standalone in auth request) should also result in being one of the members of the grant query call, that's for the resulting specification to be a general purpose - to return everything grant related.
>> 
>> Makes sense, added it. https://bitbucket.org/openid/fapi/pull-requests/152/added-resources-resource-indicators-to-the/diff
>> 
>> > 
>> > I think the recommendation for grant_id value is a bit awkward - talking about resulting octet length, i'd say it should recommend a secure prng generated byte/bitsize that is then encoded using e.g. hex or base64url.
>> 
>> I just used the text from PKCE but I’m not bound to it. May I ask you to propose text? 
>> 
>> > 
>> > Did you consider returning a grant_uri instead of grant_id? That way the AS is free to choose any URL scheme for its endpoint, as well as not needing a new endpoint in discovery altogether.
>> 
>> Yes, I did. I'm personally in favour of the grant id since the whole OAuth 2 framework is built on ids and corresponding endpoints. Introducing a new pattern in this extension deviates from the established patterns. I see the advantage in terms of flexibility but is it worth a different pattern? I think it would have been the right decision back when refresh tokens were designed as part of RFC6749. 
>> 
>> Moreover, I think it is possible for an AS to support the request parameters without exposing the grant management API. The parameters by itself are a useful feature even if the deployment does not have a need to let clients query the status or even delete grants. And lastly, a URI would increase the authorization request size.
>> 
>> best regards,
>> Torsten. 
>> 
>> > 
>> > Best,
>> > Filip
>> > 
>> > 
>> > On Wed, 11 Mar 2020 at 13:01, Torsten Lodderstedt via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>> > Hi all, 
>> > 
>> > I just merged the first revision of the new Grant Management Extension for OAuth into the master.  
>> > 
>> > Please take a look at https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md and give feedback. 
>> > 
>> > For your convenience, I attached the HTML version to this e-Mail. 
>> > 
>> > best regards,
>> > Torsten. 
>> > 
>> > _______________________________________________
>> > Openid-specs-fapi mailing list
>> > Openid-specs-fapi at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 
> 
> -- 
> Dave Tonge
> CTO
> 
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> Moneyhub Financial Technology Limited 2018 ©
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.



More information about the Openid-specs-fapi mailing list