CIBA - Fraud Indicator Standards and Signed Communication Mechanism of them.

[Ralph Bragg]

After the meeting with latest Open Banking workshop on decoupled authenticaton mechanisms there was broad support for CIBA as a standard.

There was strong support for the RP to provide standardized information about the consumption device to the OP as part of this flow for fraud and threat decisioning.

Any context information that's provided, where the expectation is that an OP will rely on it to inform risk decisions e.g SCA or not SCA, should be transmitted in a way that supports nonrepudiation - signed payload.

[Tom Jones]

Is the "consumption device" a smart phone/tablet? Then your will be disappointed in the result. I have an open issue to assure that the user device and software native client can be known to the user, but there seems to be little support for even that much. I do not think that sufficient concern has been raised about the user device.

[Ralph Bragg]

The consumption device in this case is most likely to be a POS terminal that is within the RP's control. If it's not and it can not reliable assert information about the device (location, OS, etc etc) then it should not assert anything and leave it up to the bank.

There are concerns from ASPSPs regarding their sanctions obligations if they're not sure where the payment request is initiating from.

[Tom Jones]

This is why i wanted strong identity for the devices. There have been lots of attacks against devices of this sort as well as phones.

[Nat Sakimura]

During the call on June 12, Tony raised the question about the increase in the payload and the impact on the through put. We should look at the typical size increase.

[Nat Sakimura]

After the meeting with latest Open Banking workshop on decoupled authenticaton mechanisms there was broad support for CIBA as a standard.

There was strong support for the RP to provide standardized information about the consumption device to the OP as part of this flow for fraud and threat decisioning.

Any context information that's provided, where the expectation is that an OP will rely on it to inform risk decisions e.g SCA or not SCA, should be transmitted in a way that supports nonrepudiation - signed payload.

[Dave Tonge]

Defining a spec with metadata for devices is not going to be possible in CIBA. I suggest that we again make a note with a suggestion on the different ways this metadata could be communicated between the RP and OP

[Dave Tonge]

So interestingly this also aligns that the discussion of where to put the intent id. As mentioned previously the core spec says this about the signed request: “MAY contain additional parameters defined by extension or profile”

‌

I suggest therefore that we add a note along the lines of:

NOTE: The AS may require the Client to sent information about 
the Consumption Device in the authentication request, for example
the location and type of device. Such information can be sent in 
an additional parameter in the signed authentication request as 
specified by the AS. 

[Torsten Lodderstedt]

I agree with your proposal to recommend use of additional parameters to carry other information.

[Joseph Heenan]

This was discussed on yesterday’s call.

There was quite a bit of discussion between two alternatives:

1. Saying that this information should be passed in additional parameters, or:
2. Defining a parameter and format, but leaving the details undefined

Vendors on the call had a preference for ‘2’, as they felt it would allow them to make life easier for their customers that need to implement this.

The suggestion mentioned on the call was a ‘login_context_token’ parameter containing json, and I think it was then suggested to remove ‘token’ from that leaving ‘login_context’.

[Joseph Heenan]

I have proposed text in https://bitbucket.org/openid/fapi/pull-requests/122/ciba-define-mechanism-to-pass-fraud-threat/diff , namely:

may require clients to provide information to inform fraud and threat decisions in a JSON object (the contents of which are not defined by this specification) passed in a login_context claim in the Signed Authentication Request

[Joseph Heenan]

I should add: there was a lot of discussion above that the information should be signed.

This text proposes that the new object is included in the signed authentication request, and hence I don’t believe the object itself also needs to be signed. Is there a use case where the authorization server may want the client to send information that has been signed by a different party or with a different key? If there is, is there any solution on the table that is better than allowing the AS to define that one of the claims in the new login_context object should be a jws?

(I cannot think of a better method just now, so believe the text in my pull request is sufficient.)

[Ralph Bragg]

@Joseph Heenan I agree, if it needs to be signed then a jws is most appropriate.

[Joseph Heenan]

CIBA: Define mechanism to pass fraud/threat information

The working group members present on the 19th June 2019 call felt that explicitly defining a parameter and format to allow the client to pass additional contextual information would be beneficial, allowing vendors of authorization servers to expose the information to their customers in a consistent way.

closes #146

→ <<cset efd7a46b42fb>>