Encrypted login hint

[Torsten Lodderstedt]

The discovery service may ask the user for her MSISDN in order to determin the user's MNO. If available, this data shall be passed to the OP via the RP. In order to preserve privacy, this MSISDN shall not be shipped in the clear but as an encrypted parameter.

The MODRNA profile shall define an extension parameter to allow the RP to pass this data as additional hint to the OP.

Idea: disocvery service returns MSISDN in an encrypted JWT. This JWT is sent to the OP using a new parameter login_hint_jwt.

[Jörg Connotte]

As the encrypted hint has to be transported from the discovery service to the OP the encryption has to be done using a public key of the OP.

[Jörg Connotte]

The discovery profile specifies the following possible content * mnc / mcc * msisdn * login_hint * ip-address

If login_hint and msisdn are present login_hint which should be preferred? mnc / mcc don't actually identify a user.

[Torsten Lodderstedt]

Which discovery profile are you referring to?

[Torsten Lodderstedt]

Consensus from WG call: * reduce the claims to MSISDN, iss, aud, and iat * JWT is encrypted with public key of MNO * JWT is signed with private key of issuer * login_hint_token is moved to authentication spec

[Jörg Connotte]

Is this correct?: If the login_hint_token ist signed the 'iss' attribute in the token is mandatory and must point to a jwks_uri (either directly or indirectly)

[Torsten Lodderstedt]

I think the iss is mandatory, otherwise the OP can only accept such tokens from a single entity.

Regarding the value: In my opinion, we have three options: - make it a name/id only and leave it to the OP implementation to determine the corresponding public key(s) - make it a URL and define a algorithm to deduce a JWK URL from it - make it a JWK URL

I'm not quite sure whether the key shall always be obtained dynamically. So I personally tend to suggest a combination if 1 and 2, meaning if the iss is a URL then there is a way to determine the JWK URL.

I wondering whether this question had been discussed in the context of software statements. @John/Nat: Could you fill in?

[Torsten Lodderstedt]

the login hint token is first signed and encrypted afterwards JWE(JWS(JWT))

discussion in call: * iss refers to the entity signing and encrypting the JWT * iss is a HTTPS URL * key used to verify signature is obtained from a URL. This URL is build based on the iss and points to a file residing underneath <iss>/.well-known, e.g.. <iss>/.well-known/login_hint_token_jwks_file * the encryption key is exposed by the OP using the ordinary OIDC mechanisms (openid-configuration)

[Torsten Lodderstedt]

Question: Is is required to sign the login token hint? Primary goal is to protect the user's MSISDN from being exposed to a RP Reasons to sign the login_hint_sign: - control the source - authenticate/authorize the source

[Torsten Lodderstedt]

Other potential use case for login token hint. A RP wants to give a user the option to login at the OP with an user account she used before. Because the RP does not know the MSISDN or e-Mail address, it cannot use the login hint for that purpose. It can also not use the id token hint because this would force the OP to login the user with the exact same identity or return an error "login required". The RP could use the ppid/aud or directly use the id token.

topic is subject of further discussions

[Jörg Connotte]

Resolved in MODRNA authentication with the login_hint_token.