CIBA: Authentication request and context parameters

Siva Boyalakuntla Account Deactivated

Hi,

Seems, there is a mistake, this is proposed under CIBA, whereas the examples are saying user-agent.. using a web browser which is related to openid connect core. iin CIBA there is no user agent.

I believe with openid connect core parameters related to user agent [web browser] on any device and also for native applications can be sent.

where as B2B scenatios CIBA can be used.... from a server.. then different parameters.

if-we are registering, then we metadata parameters may need-to Register them for openid connect core [front channel] and CIBA [back channel] separately... !!

send user-agent related parameters, in CIBA, are not relevant I believe.

2018-10-02T15:47:56+00:00

Petteri Stenius reporter

Hi Siva, I'm not saying a web browser is required for CIBA. In many cases CIBA is likely initiated by something else. However, I think use cases exists where CIBA is initiated by action originating from a web browser.

2018-10-03T07:52:24+00:00

Brian Campbell

changed milestone to CIBA Post-Implementer's Draft

2018-10-22T17:51:28+00:00

Siva Boyalakuntla Account Deactivated

HI Agree with that. context parameter should be included to have meaningful information to the user. But, instead of registering context allowed strings, which are not flexible, we can keep it open and as discussed in today's call, we can include spam prevention code, when context parameter is used. In this case then user must have already registered with SP and security context must have been established. Support this to include in CIBA( back channel) as well as OIDC core ( front channel)

Just think over it, if anybody has any better ideas, please share.

best regards, /Siva

2018-11-20T16:02:37+00:00

Dave Tonge

We discussed this on the last call and I suggested 3 options:

We add a section in security considerations where we recommend implementers consider sending additional metadata. However we don't prescribe the manner in which the metadata should be sent or the schema that it should follow. In addition we could let profiles of the core CIBA spec be more specific about this.
We take the approach that is in the FAPI specs and specify some headers that could be used for things like IP address, geolocation, etc.For example FAPI has this header: x-fapi-customer-ip-address. These headers would probably not be mandatory as different ecosystems will have different requirements around what metadata must be passed.
We specify a different place for implementers to pass context metadata, for example the login_hint_token or additional params in the backchannel auth request. Given that the login_hint (and login_hint_token) are opaque from the point of view of the spec, it may be a good place to pass such metadata.

From my perspective I'm not in favour of option 2 as I think headers are the wrong place for such information - especially if its going to be used for a fraud decision - it really should be signed by the RP. I am tempted by option 3, but I think it will be hard to specify something like this for CIBA alone. From my perspective I think it could be helpful if there was a spec for a set of standard assertions that an RP could make about a user, e.g.:

{
  location: {"type": "Point", "coordinates": [lon, lat]} // geoJSON - RFC7946
  auth_time: 1551772848, // the time that the RP "authenticated" the user
  ip: 8.8.8.8, // the ip address of the user
  // etc
}

Thinking about this further I believe that a Security Event Token may be the right container for this type of data (https://datatracker.ietf.org/doc/rfc8417/?include_text=1). Essentially we have a user who has some type of session with the RP and the RP wants to convey some context of that session to the OP.

An example SET could be:

{
     "iss": "https://RP",
     "iat": 1458496025,
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "aud": [
       "https://OP"
     ],
     "toe": 1458496015,
     "events": {
       "some-uri-referring-to-online-or-physical-session": {
          "location":  {"type": "Point", "coordinates": [lon, lat]},
          // etc.
       }
     }
   }

Having said all of this, I think that for the core CIBA spec we may only be able to take option 1 and put something in the security considerations.

2019-03-05T08:13:57+00:00

Dave Tonge

We discussed that we would go with option 1, but that in the future we may consider bringing something into the spec based on what is worked on profiles or real-world implementations. However at the moment it is too early to standardise something in this area.

I will propose some text for the security considerations.