[Openid-specs-fapi] Grant Management Draft

Torsten Lodderstedt torsten at lodderstedt.net
Sat Mar 14 21:32:34 UTC 2020


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
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200314/86825d34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3629 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200314/86825d34/attachment-0001.p7s>


More information about the Openid-specs-fapi mailing list