[Openid-specs-fapi] [Bitbucket] Pull request #90: new document describing the lodging intent pattern (openid/fapi)
dave.tonge at momentumft.co.uk
Fri Feb 1 05:53:18 UTC 2019
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.
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
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.
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
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.
FWIW we are planing to launch a payments API that uses the request object
endpoint pattern described above.
On Thu, 31 Jan 2019 at 18:46, Torsten Lodderstedt <torsten at lodderstedt.net>
> 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,
> 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
> [image: dgtonge]
> *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.
> View this pull request
> or add a comment by replying to this email.
> Unwatch this pull request
> to stop receiving email updates. [image: Bitbucket]
[image: Moneyhub Enterprise]
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.
Technology is registered in England & Wales, company registration number
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi