CIBA: Authentication request and context parameters

Issue #91 resolved
Petteri Stenius created an issue

This topic was briefly discussed in yesterday's call (September 25)

It was recognized there is need to let client send context and metadata parameters to OP as part of authentication request.

Examples of possible context and metadata parameters that may be useful

  • IP address of user agent, for example when authentication is initiated by a user using a web browser
  • Type of device initiating authentication (vending machine, ATM etc)
  • GPS location coordinates of device initiating authentication
  • others

At a minimum there should be a registry of names for context and metadata parameters. Should it also be possible for an OP to define parameters that are mandatory?

Comments (9)

  1. Siva Boyalakuntla Account Deactivated


    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.

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

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

  4. Dave Tonge

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

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

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

    3. 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:, // 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 ( 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": [
         "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.

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

  6. Log in to comment