[Openid-specs-fapi] Grant Management Draft

Wed Mar 18 16:57:52 UTC 2020

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.

> API authorization
This is a tricky one, I feel the current situation is too broad and too
specific. 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

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

> 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?

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

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
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200318/c4109d0a/attachment-0001.html>