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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Feb 6 16:15:16 UTC 2019


Hi Dave,

> Am 04.02.2019 um 11:58 schrieb Dave Tonge <dave.tonge at momentumft.co.uk>:
> 
> 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.

Great!

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

sure. Everything else is redundant. Unfortunately, neither OIDC nor JAR (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-5.2.2) support it right now. 

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

how many of the implementations you tried support structured values for essential claims?

>  - its relatively easy to use OIDC certified RP implementations to create the request object.

The approach you are using seems to be very practical on first sight, but it does not fit the semantics of OIDC essential claims. The request effectively tells the OP to attest the claim "mh:payment" with the respective values passed in the claims object. This  means the OP MUST attest this claim in the ID Token, which does not make sense in your context. You want to further parametrize the authorization transaction. Moreover, and I have stated that many times before, it requires the client to use OpenID Connect for API authorization. Here is my short list of the consequences:
- client needs to turn on OIDC using the scope value „openid“
- AS needs to support OIDC (does Spring OAuth support OIDC?)
- client uses the response type „code id_token“
- AS needs to put a reasonable sub value in the ID Token What do you use?
-- if you use a real user id, you need to ask the user for permission to share it with the RP
-- if you use an ephemeral id, the same client cannot latter on use OpenID Connect with the same AS/OP

I unterstand you went that way in your product but I’m reluctant to support standardizing this approach.

There are obvious alternatives since the request object, as a JSON document, allows to carry the data in other ways as well. 

One could add all data carried in a lodging intent in a JSON structure, e.g. 

{
    "client_id": "the-client-id",
    "scope": "payment openid",
    „challenge": "the PKCE challenge value",
    "state": "the state value",
    "exp": 1544524408,
    "redirect_uri": "https://client/callback",
    "response_type": "code",
    "payment": {
         "amount": 100,
         "payeeRef": "payee ref",
          "payerRef": "payer ref",
          "payeeId": "the id of the payee" 
     }
}

And voila, it's plain OAuth and simple to parse. 

One could also one step further and explicitly link the scope value and the accompanying data, e.g.

{
    "client_id": "the-client-id",
    "scope": „payment:payment_data1 openid",
    „challenge": "the PKCE challenge value",
    "state": "the state value",
    "exp": 1544524408,
    "redirect_uri": "https://client/callback",
    "response_type": "code",
    "payment_data1": {
         "amount": 100,
         "payeeRef": "payee ref",
          "payerRef": "payer ref",
          "payeeId": "the id of the payee" 
     }
}

This would also allow to convey multiple data sets.

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

From a product/project implementation perspective, you might be right. But we don’t need to wait.  We are a working group of a standardization body. We set standards.

Moreover, the draft is already in IESG review.
@Nat: when do you expect this to be done?

I personally think a plain OAuth solution based on the request object hosted with the AS is better suited to address the use cases than the lodging intent since it is self contained and versatile.

best regards,
Torsten.

> 
> 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
> 
> 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/20190206/05ab5296/attachment.p7s>


More information about the Openid-specs-fapi mailing list