[Openid-specs-fapi] Grant Management Draft

Filip Skokan panva.ip at gmail.com
Sat Mar 14 17:48:30 UTC 2020


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.

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... :(

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/af3a0445/attachment.html>


More information about the Openid-specs-fapi mailing list