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

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2018-06-08

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.

---

Bitbucket status: closed

Bitbucket origin: issue 146

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2018-06-08

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.

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2018-06-08

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.

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2018-06-09

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.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2018-06-12

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.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2019-05-15

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.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-06-05

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

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-06-19

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. 

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2019-06-19

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

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2019-06-20

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

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2019-06-21

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