1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. mobile
  4. Issues

CIBA - Support for Spam Prevention code in Authentication Request

Issue #62 resolved
Petteri Stenius created an issue

In the Finnish Mobile PKI service end users may opt-in for a Spam Prevention code [1]. The code must be delivered with the user's Phone Number to the Mobile PKI operator to initiate mobile authentication process.

The Estonian and Lithuanian Mobile PKI service requires as input the end user's Phone Number and Personal Identification Code [2].

Should there be support for these kinds of fields in the CIBA Authentication Request?

It may be possible to encode these fields as service specific claims in login_hint_token, unless the login_hint_token is received from the discovery service.

[1] http://mobiilivarmenne.fi/wp-content/uploads/2017/05/MSS_FiCom_Implementation_guideline.pdf, chapter 6.2.3.2

[2] http://sk-eid.github.io/dds-documentation/#starting-mobile-id-operations

Comments (25)

  3. Petteri Stenius reporter

    As agreed in meeting on Feb 20th here's a proposal

    The name of the parameter is user_code. Influenced by user_code parameter in OAuth device flow spec.

    4.1. Authentication Request

    user_code

    OPTIONAL. A secret code, such as password or pin, known only to the user. The code is used to authorize sending an authentication request to user's authentication device.

    4.1.1. User code

    User code is a mechanism to prevent unsolicited authentication requests from appearing on user's authentication device.

    User code is optional. The authentication service may allow users without registered user code. Clients that establish a security context with the user before sending an authentication request should not be required to send a user code.

    Registering a user code for a user is not in scope of this specification. Examples include a facility provided by the authentication device or SMS text messages.

    6.5. Authentication Error Response

    missing_user_code

    User code is required but was missing from request

    invalid_user_code

    User code was invalid

  7. Dave Tonge

    To discuss on the call:

    . Clients that establish a security context with the user before sending an authentication request should not be required to send a user code.

  8. Dave Tonge

    We discussed this on the call.

    • the sentence about "security context" refers to the fact that a user may have already interacted with the RP and OP previously and therefore wouldn't need the code each time
    • there will be a need for some discovery metadata for this
    • the requirement to pass a user code will vary by user, so if an OP supports it, an RP will need to handle the missing_user_code error

    Brian also suggested that something similar could be achieved by the RP first performing a ROPC token grant with the user hint and the user code. The resulting access token could then be used to authenticate at the backchannel endpoint.

  9. Petteri Stenius reporter

    I propose to add the following text to specify OP and Client metadata parameters:

    Provider metadata

    user_code_parameter_supported = true | false

    OPTIONAL. Boolean value specifying whether the OP supports use of the user_code parameter, with true indicating support. If omitted, the default value is false.

    Client registration

    user_code_parameter = true | false

    OPTIONAL. Boolean value specifying whether the Client must be able to send the user_code parameter. If omitted, the default value is false. This parameter only applies when OP parameter user_code_parameter_supported is true.

    Let's review this on the next call.

  10. Dave Tonge

    @jeps thanks for this, please help me understand the reasoning for the client registration metadata? If an OP supports it, then wont all Clients need to be able to support it?

  11. Petteri Stenius reporter

    A client that establishes a security context with the user before sending CIBA authentication request need to register with user_code_parameter=false

  14. Dave Tonge

    Apologies for the delay, my thoughts on user code are as follows (and thanks Petteri for the PR and all the work on it so far):

    The current wording supports these registration scenarios:

    1. OP does not support
    2. OP supports and RP registers with "required"
    3. OP supports and RP registers with "not-required"
    4. OP supports and RP registers with "optional"

    1 and 3 are the same in practice, i.e. user_code shouldn't be included or processed in the backchannel auth request (should this result in errors?)

    For 2, we have the following runtime scenarios:

    • 2a. user doesn't have user-code, so RP doesn't send - this should be valid
    • 2b. user has user-code, but RP doesn't send - this should result in an user_code_required error and the RP should retry with a valid user code
    • 2c. user has user-code and RP sends - this should be valid

    For 4, we have the following runtime scenarios:

    • 4a. user doesn't have user-code, RP doesn't send, but sends user_code_omitted=true - this should be valid if the OP still trusts the RP
    • 4b. user doesn't have user-code, RP doesn't send, but sends user_code_omitted=false - should this be valid? Or should there always be an error if user_code_omitted=false but there is no user_code?
    • 4c. user does have user-code, RP doesn't send, but sends user_code_omitted=true - this should be valid if the OP still trusts the RP
    • 4d. user does have user-code, RP doesn't send, but sends user_code_omitted=false - should this be a user_code_required error or a bad request error?
    • 4e. user does have user-code, RP sends and sends user_code_omitted=false - this should be valid
    • 4f. user does have user-code, RP sends and sends user_code_omitted=true - this should be a bad request

    I think this is too complex and I suggest something simpler:

    • OP discovery metadata: backchannel_user_code_parameter_supported to indicate that OP supports user_code
    • No client registration metadata
    • Only user_code param, (no user_code_omitted param)
    • user_code_required error

    We can then have the following scenarios:

    1. OP doesn't support
    2. OP supports, user doesn't have code, RP doesn't send code - request is valid
    3. OP supports, user has code, RP sends code - request is valid
    4. OP supports, RP has existing security context, user has code, RP doesn't send code - request is valid
    5. OP supports, RP does not have existing security context, user has code, RP doesn't send code - a user_code_required error is returned

    Ultimately if the OP supports user_code and a user has registered a user_code and an RP doesn't send it, then this is a policy decision for the OP to make as to whether it should accept the request. I'm not sure of the benefit of trying to represent that policy decision in this specification. I can see a possibility that even if an RP registered with "optional" support and sent the user_code_omitted param, the OP may still decide to send a user_code_required error. So therefore the RP will always have to deal with that error.

    I think that with login_tokens and login_hint_tokens we have other mechanism for the RP to convey assurances about the security context of the user. For example in an OpenBanking scenario the login_hint_token may well be generated by the OP and passed to the RP by the user out of band. In the use-case of step-up auth in a call-centre, the RP could sign a login_token with the caller_id it received. The result would be the same - the OP would need to make a policy based decision on whether to bypass the requirement to require user_code.

  15. Siva Boyalakuntla Account Deactivated

    Ok, now I understand it it is spam prevention code. Yes, this is good, but few things to consider :

    1. leakage of user_code.
    2. if user_code is leaked then anyway user might get spam messages? What are the security considerations?
    3. is there any mechanism so that user can change the user_code, RP and OP will get updates ?? what is the process?
    4. although security context is already established, still SP keep on sending user_code is it allowed?
    5. Is it possible in the future to issue one time valid user_codes programmatically to the SP ? for example once the user_code is used, then for the same user OP can send automatically another user_code, thus stopping the leakage of the user _code?

    best regards, /Siva

  16. Petteri Stenius reporter

    1, 2 and 3) Registering user code is out of scope of this spec. I have experience from a service where end users register user code by sending user code as SMS text message to OP. You could also implement user code registration in the user interface of the authentication device.

    4) A client that establish security context shoud be registered with backchannel_user_code_parameter=false. Such a client must not send user code.

    5) Yes I think one time user codes are possible. The authentication device could for example generate the one time user code and display the code in its user interface.

  17. Petteri Stenius reporter

    I have updated the pull request https://bitbucket.org/openid/mobile/pull-requests/39/default/diff

    Changes

    • client registration parameter backchannel_user_code_parameter is boolean, with default value of true
    • removed user_code_omitted request parameter
    • update descriptions

    A rendering of updated text is here

    https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://bitbucket.org/jeps/openid-mobile-issue-62/raw/default/draft-mobile-client-initiated-backchannel-authentication.xml&modeAsFormat=html/ascii

  18. Siva Boyalakuntla Account Deactivated

    HI,

    can't we use simply 'user_code' as the parameter name ? Moreover, this concept is good and can also be applicable to front channel use cases. all request parameters are parameters, hence the suffix to use _parameter may not be necessary.

    regarding backchannel prefix, if we prefer to keep backchannel and front channel wording for parameter names

    bc_user_code fc_user_code may be ..

    But, simply user_code or user_spam_code may be good.

    proposal :

    user_code or user_spam_code ( Just keeping the bytes limitation for the request in front channel ).

    if we want to keep backchannel separately and front channel separately. then bc_user_code or bc_user_spam_code may be preferred.

    May be good to mention : 1. security considerations : related to user code [leakage etc. ] 2. one time user_code usage.. recommendation.

    Just think over it.

    best regards, /Siva

  19. Dave Tonge

    HI @Siva_boyalakuntla so I think that a spam prevention code is appropriate for backchannel auth but not for front channel. CIBA flows mean that the OP will push out to the users authentication device, whereas for front-channel flows the user will need to actively click a link/button to follow a redirection path to the OP, i.e. the front-channel flow requires a users action, whereas the backchannel flow doesn't.

    With regards to security considerations it may be appropriate to add something about this. I think the idea is that user_code is not a one-time use item, but rather something like a "pin" that the user will configure with the OP to use with any RP.

    About user_code leaking - I'm not sure what we should say here, maybe just that OPs should provide users the ability to reset a user_code?

    @jeps are RPs allowed to store the user_code for subsequent interactions? We should probably mention something about this.

  20. Petteri Stenius reporter

    In the front channel the user's browser is usually redirected to a logon form provided by the OP. The logon form could prompt for user code if necessary. However I think prompting for user code and any other details of the logon form are not in scope of OpenID Connect MODRNA profile.

    RP or Client should not store the user code. Also they cannot assume user code remains the same between authentication transactions.

    Yes, OP should provide method to change user code.

  21. Siva Boyalakuntla Account Deactivated

    Hi,

    regarding security considerations etc,

    somehow we tie user_code to the RP's client_id and generate if it is not for one time usage or leaked then OP can detect it. the spec should define a recommended or choices [similar to PPID generation] to generate the user code. In this way any user code generated for a given user also tied to one RP service only.

    I agree that in the backchannel it is necessary than in FC.

    so following requirements seems to be mandatory : 1. user code may be one time use 2. user_code could be tied to one RP only. 3. user_code should not stored by RP or client 4. user_code can be changed between two transactions 5. OP should provide method to change user_code 6. Can user give permission to OP to generate it automatically.

    please think over it .

    best regards, /Siva

  22. Brian Campbell

    I think I generally agree with @dgtonge's analysis and suggestions in his comment from 2018-11-20. However, while it is ultimately a policy decision for the OP to make as to whether it should accept the request, I think it is useful to inform the OP of the the different cases of a user_code being omitted because the client has an established security context for the user vs. other reasons is might be omitted (user has no code established or client can't or won't collect user code).

    As such, I'd suggest an alternative to the "user_code_omitted" request parameter to signal that particular situation: let's define a special collision resistant value that a client/RP can send for user_code that says effectively, "I'm already pretty confident I know who this user is by having some previously established security context for them so I am explicitly not sending a user code". Something like "urn:openid:ciba:something:something:something:secureish-user-context-established" or "[[[it's cool man, I know how the user is]]]" but better. Trust still needs to be placed in the client and the OP still ultimately makes a policy decision about servicing a request. But I believe this bit of info is useful in that policy decision and isn't otherwise easily conveyed.

    Yes, with login_tokens and login_hint_tokens we have some other mechanism for the RP that can be used to convey assurances about the security context of the user. But, honestly, I'm having a hard time wrapping my head around how some/all of them might really work and relying on the hint for that starts to overload it in ways that may make just identifying the end-user for whom authentication is being requested more difficult or complicated.

  23. Dave Tonge

    So the current PR supports 2 types of client registration - so an RP who wants to support the "optional" behaviour would register 2 clients.

    @b_d_c are you suggesting that we rather have a single client registration (i.e. no backchannel_user_code_parameter registration param) and that rather a client can send a special param as the user-code to indicate that they an existing security context?

    I'm happy with either suggestion. I suppose the advantage with the current PR is that the OP can allow / disallow the privilege of a client omitting user-code at registration time. But the advantage with Brian's suggestion is that the RP would only need to register 1 client.

    In line with comments above I suggest we add some security considerations similar to those proposed by @Siva_boyalakuntla

  24. Brian Campbell

    Per the Nov 27 call, the WG decided to ignore my "magic user code value" idea. And security considerations are good but need to be reflective of reality.

  26. Log in to comment
Assignee
Type
proposal
Priority
minor
Status
resolved
Component
CIBA
Milestone
CIBA Implementer's Draft
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!