[Openid-specs-fapi] [Bitbucket] Pull request #90: new document describing the lodging intent pattern (openid/fapi)
Dave Tonge
dave.tonge at momentumft.co.uk
Mon Feb 4 10:58:00 UTC 2019
Hi Torsten,
Sorry, I don't think I was clear in my email - we don't put an intent id in
the request object, rather we include all the intent data inside the
request object.
Here is an example of the flow.
The client creates a request object with a payload like this:
{
"client_id": "the-client-id",
"scope": "payment openid",
"nonce": "the nonce value",
"state": "the state value",
"claims": {
"id_token": {
"mh:payment": {
"essential": true,
"value": {
"amount": 100,
"payeeRef": "payee ref",
"payerRef": "payer ref",
"payeeId": "the id of the payee"
}
}
}
},
"exp": 1544524408,
"redirect_uri": "https://client/callback",
"response_type": "code id_token",
"iss": "the-client-id",
"aud": "https://AS"
}
note re payeeId - this is a reference to the payee account. Our use case is
to allow payments from arbitrary accounts to a pre-defined account.
The client posts this request object to https://AS/request
And gets back a request_uri,
e.g. urn:x-mh-request:39c28c28-9cf4-44bd-80cd-9ff68c705aaa
Note, the AS verifies the request object prior to saving it and returning a
request_uri.
The client now constructs the auth request as follows:
https://AS/auth?request_uri=urn:x-mh-request:39c28c28-9cf4-44bd-80cd-9ff68c705aaa
(note that we support but don't require client_id, scope or response_type
to be sent as additional params).
On the authorisation server, we can retrieve all the auth params, many of
which don't need to be re-verified and create the consent page.
While putting the intent data in the claims parameter may be a bit
convoluted but it has the following advantages:
- in the OIDC certified OP that we use, its easy to get access to the
intent data to create the consent page
- its relatively easy to use OIDC certified RP implementations to create
the request object.
Using the pattern of requiring a pre-registered request object also gives
us the following advantages:
- we can enforce certain response_types (e.g. for payments we require code
id_token)
- we have a single signed payload that we can store that has all of the
data associated with the payment
When https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 lands it will
be possible to use a similar pattern without OIDC.
At that point we would probably have to define a custom collision resistant
claim for the request object and put the intent data there, rather than
using the claims parameter.
Dave
On Fri, 1 Feb 2019 at 12:08, Torsten Lodderstedt <torsten at lodderstedt.net>
wrote:
> 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.
>
>
--
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/20190204/2cbfd36a/attachment-0001.html>
More information about the Openid-specs-fapi
mailing list