<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Torsten</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I've reviewed the draft and here are some comments:<br><br>>  Should the AS always return the grant_id if the client once asked for it?<br>Instinctively I would say no, it would place an extra burden on the AS for not much benefit</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">>  Should the AS rotate grant ids for privacy reasons?<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I would say no. I think it is useful to think of these grants as restful resources, and rotating ids will cause confusion.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">> API authorization</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I would suggest that either:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">1. the endpoints are assumed to be at the AS and are protected through standard client auth</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">2. security for the endpoints is not specified</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">> Revoke Grant</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I think we need to talk about the relationship with <a href="https://tools.ietf.org/html/rfc7009" style="font-family:Arial,Helvetica,sans-serif">https://tools.ietf.org/html/rfc7009</a> and what the AS should do with any tokens associated with a grant.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">> <span style="font-family:Arial,Helvetica,sans-serif">grant_id potentially could be shared by different client_id belonging to the same entity.</span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">This may well be desirable. Perhaps we should spec how to do this using sector identifiers?</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Thanks so much to all those who have worked on the document so far.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Dave</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 14 Mar 2020 at 22:32, Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">Hi Filip,</div><div dir="ltr"><br><blockquote type="cite">Am 14.03.2020 um 18:49 schrieb Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Torsten,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">I just used the text from PKCE but I’m not bound to it. May I ask you to propose text?</span></blockquote><div><br></div><div>how's this? </div><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div>thanks. What would be a sensible choice for xxx?<div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">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.</span></blockquote><div><br></div><div>It's not necessarily a new pattern, dynamic client registration's `registration_client_uri` uses the same pattern. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">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.</span></blockquote><div><br></div><div>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... :(</div></div></div></div></blockquote><div><br></div>I don’t feel appending the id is a big deal.</div><div><br></div><div>best regards,</div><div>Torsten.<br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><div><br clear="all"><div><div dir="ltr">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 14 Mar 2020 at 18:07, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Filip, <br>
<br>
> On 11. Mar 2020, at 14:01, Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>> wrote:<br>
> <br>
> Hello Torsten,<br>
> <br>
> Thank you for putting this together, here's my feedback:<br>
> <br>
> 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.<br>
<br>
Makes sense, added it. <a href="https://bitbucket.org/openid/fapi/pull-requests/152/added-resources-resource-indicators-to-the/diff" rel="noreferrer" target="_blank">https://bitbucket.org/openid/fapi/pull-requests/152/added-resources-resource-indicators-to-the/diff</a><br>
<br>
> <br>
> 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.<br>
<br>
I just used the text from PKCE but I’m not bound to it. May I ask you to propose text? <br>
<br>
> <br>
> 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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
best regards,<br>
Torsten. <br>
<br>
> <br>
> Best,<br>
> Filip<br>
> <br>
> <br>
> On Wed, 11 Mar 2020 at 13:01, Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<br>
> Hi all, <br>
> <br>
> I just merged the first revision of the new Grant Management Extension for OAuth into the master.  <br>
> <br>
> Please take a look at <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md" rel="noreferrer" target="_blank">https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md</a> and give feedback. <br>
> <br>
> For your convenience, I attached the HTML version to this e-Mail. <br>
> <br>
> best regards,<br>
> Torsten. <br>
> <br>
> _______________________________________________<br>
> Openid-specs-fapi mailing list<br>
> <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
<br>
</blockquote></div>
</div></blockquote></div></div>_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:"Open Sans";font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4"><div style="font-weight:400;color:rgb(51,51,51);line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border: none; padding: 0px; border-radius: 2px; margin: 7px;"></a></div><div style="padding:8px 0px"><div style="padding:8px 0px"><div style="letter-spacing:normal;line-height:normal"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br style="color:rgb(0,164,183);font-size:11px;line-height:15.925px"></div><div style="letter-spacing:normal;line-height:normal"><span style="font-size:11px;line-height:15.925px"><br></span></div><div style="color:rgb(97,97,97);font-family:"Open Sans";letter-spacing:normal"><div style="line-height:1.4"><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em">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 </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em;background-color:transparent">(FRN </span><span style="color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;font-size:10.5px;font-weight:700">809360</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. M</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:10.5px">oneyhub</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> Financial Technology is registered in England & Wales, company registration number </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> </span><span style="font-weight:bold;color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">06909772</span><span style="background-color:transparent"><font color="#333333" face="lato, open sans, arial, sans-serif"><span style="font-size:0.75em"> .</span></font></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> Financial Technology Limited 2018 </span><span style="background-color:transparent;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:x-small">©</span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:0.75em"><br></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">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.</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>