- marked as critical
Encrypted login hint
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.
Comments (11)
-
reporter -
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.
-
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.
-
reporter Which discovery profile are you referring to?
-
reporter 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
-
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)
-
reporter 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?
-
reporter 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)
-
reporter 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
-
reporter 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
-
- edited description
- changed status to resolved
Resolved in MODRNA authentication with the login_hint_token.
- Log in to comment