[Openid-specs-fapi] [Bitbucket] Pull request #90: new document describing the lodging intent pattern (openid/fapi)

Torsten Lodderstedt torsten at lodderstedt.net
Fri Feb 1 11:08:46 UTC 2019


Hi Dave,

> Am 01.02.2019 um 06:53 schrieb Dave Tonge <dave.tonge at momentumft.co.uk>:
> 
> Hi Torsten,
> 
> So at the moment in FAPI part 2 we define a request object endpoint at the AS - that the client can use to post request objects to and receive back a request uri. Part of the rationale behind adding that was that it allowed the client to include all manner of custom claims in the request object without worrying about the size of the JWT as it would be sent via the backchannel rather than the frontchannel. 

Is the size of the JWT really an issue? In the pattern you are describing its just the intend id sent via this authorization request. 

I think this proposal is not tight to custom claims. If there is a size issue, it would be the same if the AS uses the parameterized scope value or additional URI request parameters to convey the intend id. 

> 
> I have to admit I was quite attracted to this as an option for lodging intent. If we consider the fact that in order for the AS to generate the appropriate consent screen it needs to know:
>  - the client
>  - the redirect_uri (if following the Google pattern of showing the host part of the redirect_uri to the user)
>  - the scope
>  - optionally the claims param
>  - any "intent' that is referred to by either the scope, or the claims param

+ the AS needs the data stored in the lodging intent itself. I would consider the request_uri pattern really attractive if the intent data would come with it directly. Otherwise, there is a request_uri referring to a request object that in turn refers to a lodging intend. To me this seems to be quite complex. 

> 
> I quite liked the idea of bundling all that information into the request object. The auth url the user is redirected to becomes very simple: https://AS/auth?request_uri=urn:as-namesapce:some-id. And the AS has all the information in one place to know how to generate the consent screen. There is an added benefit that the AS can validate all the params in advance and return errors via the backchannel rather than errors having to be returned via the front channel.

I agree. But in order to really check the request, the AS needs to also access the lodging intent in this process. So again, putting this data in the request object would be a better bundling IMHO.

> 
> Having said that I know that many people think this is mixing concerns and that the standard OAuth params should be kept separate from custom intent values, and that the pattern you've described in the document is the better approach.

The (1) representation of the pointer to the lodging intent and the (2) way the authorization request is conveyed to the AS are two different (I think orthogonal) aspects.  

(1) Representation of the lodging intent: using OIDC custom claims for that purpose is an option, although I have to admit I don’t think it’s the best way for various reasons. Most significantly, it requires support & to turn on OpenID for plain API authorization and (in a privacy preserving world) to assert ephemeral sub values.  That’s not only overdone but also creates problems if the same AS wants to support both pure API authz in one transaction and ID federation (OpenId) in another one. 

(2) Authorization request: we’ve got plenty of options, including URI query parameters (the traditional way), request object, request object reference (maintained by the client) and (with FAPI) request object reference (maintained by the AS/OP). OIDC custom claims could be used in conjunction with all of them like all other ways to carry the intend id. 

> 
> I think its worth a discussion though as arguably if the WG is against the approach above, then we should maybe consider removing support for the request object endpoint. 

I think having the request object reference (maintained by the AS/OP) is an attractive option if _all_ request data can be stored with it. That would be a good alternative to the lodging intent pattern. 

> 
> FWIW we are planing to launch a payments API that uses the request object endpoint pattern described above. 

Would you mind to share the API description with us?

best regards,
Torsten. 

> 
> Dave
> 
> On Thu, 31 Jan 2019 at 18:46, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> Hi Dave, 
> 
> ** taking the conversation to the list to give the WG a chance to contribute **
> 
> What do you mean by "request_uri pattern“?
> 
> kind regards,
> Torsten. 
> 
>> Anfang der weitergeleiteten Nachricht:
>> 
>> Von: "Dave Tonge" <pullrequests-reply at bitbucket.org>
>> Betreff: Aw: [Bitbucket] Pull request #90: new document describing the lodging intent pattern (openid/fapi)
>> Datum: 28. Januar 2019 um 10:30:03 MEZ
>> An: torsten at lodderstedt.net
>> 
>>                                  	
>> Dave Tonge commented on pull request #90:
>> new document describing the lodging intent pattern
>> Hi Torsten,
>> Thanks! This looks really good. Perhaps we can discuss on the next call, but I’d like to see it merged in. We can then improve it as a WG.
>> I think that as Ralph says there potentially needs to be more discussion over the RESTful nature of such a resource, i.e. should it be a long lived object that it will be possible to issue a GET /:id against, or is it a single-use ephemeral object and therefore not really RESTful.
>> We should also probably consider the request_uri pattern a bit further as its currently included in FAPI Part 2.
>> Dave
>> View this pull request or add a comment by replying to this email.
>> Unwatch this pull request to stop receiving email updates.		                     
> 
> 
> 
> -- 
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190201/41a4a1f9/attachment-0001.p7s>


More information about the Openid-specs-fapi mailing list