- edited description
Service provider wants to get authorization for a certain transaction
Issue #22
closed
A RP wants the user to authorize a certain transaction (e.g. payment). The RP must be able to describe the authorization context to the OP (via scope or another appropriate parameter).
Questions: - how is user consent indicated to RP? - is there a relationship to https://bitbucket.org/openid/mobile/issues/17/data-to-be-signed in the sense that a digital signature could be used to implement none-repudation for this consent.
Comments (7)
-
reporter
-
Proposal to distinguish Authentication, Authorization and Signature services using the OpenID Connect Authorization Request Protocol.
In our discussions it appears it could be useful to distinguish different basic services for Mobile Connect to cover electronic Identity, Authentication, Signature & Payment (also called Trusted Services). The services are distinct in the way they affect the resulting status of the end user and the returned ID_Token data. For example an authorization or signature error (refusal ?) should not log out a logged in end user. Also being in a Mobile context, all three services support the “context” request parameter, a string, to display authorization context on the authorization device. Context is a short text provided by SP to be displayed during authentication procedure on mobile device. The short text should be compatible in size and format with the acr_value requested. In the case of Mobile Connect acr_values mobile_loa2 or mobile _loa3 the size is limited to 93 bytes or 106 gsm7 characters.
All three services are OIDC services thus using the scope “openid”. An additional scope value distinguishes the services
- Authentication : scope openid
- Authorization : scope openid authorization
- Signature : scope openid signature
The three services differentiate in terms of ID_Token content and resulting status of the end user with regard to the RP
Authentication : - Request : scope openid & OPTIONAL context - Action : This service is used to authenticate a PPID and usually to login the end-user based on the ID_Token data (issuer/sub/aud/exp/iat…). - Response : ID_Token with a PPID - Resulting Status : If successful RP should log in end user, in case of error RP should log out end user
Authorization : - Request : scope openid authorization & context - Action : This service is used to authorize a RP and optionally to login the end-user based on the ID_Token data (issuer/sub/aud/exp/iat…). - Response : ID_Token with a PPID & context - Resulting Status : If successful RP can log in end user, in case of error RP should leave the end user status unchanged Note : context parameter is requested and is part of the resulting ID_Token
Signature : - Request : scope openid signature & context & OPTIONAL dtbs_uri - Action : This service is used by PPID to sign a document or string and optionally to login the end-user based on the ID_Token data (issuer/sub/aud/exp/iat…). - Response : ID_Token with a PPID & context & signature_uri - Resulting Status : If successful RP can log in end user, in case of error RP should leave the end user status unchanged Note : dtbs_uri is the location of the document to be signed, if not present the signature applies to the context string. This enables the support of a WYSIWYS service. The signature_uri is the location of the created signature.
To use scope values to distinguish between the requested services ensure a clear cut separation of services and enables IdP to selectively give access to RP to the different services.
Comments and feedbacks are welcome
-
reporter
- marked as minor
-
reporter
-
assigned issue to
Matthieu Verdier
-
assigned issue to
-
I believe I am against this proposal. while I could be convinced to support it, I would need to understand why the redundant parameter would be needed. ie.. only if these are all distinct user experiences would the additional scope parameters be needed. and I don't picture a unique user experience for all these variations therefore I don't recommend having the extra parameters. If the Service Provider wants to track the flow they can stick it in their state or nonce. Or if they want the OP/IDP to be aware they can stick an indicator in the correlation_id.
1) scope:(openid) no context 2) scope:(openid) context="xxx" 3) scope:(openid authentication) no context 4) scope:(openid authentication) context="xxxx" 5) scope:(openid authorization) no context 6) scope:(openid authorization) context="xxx" 7) scope:(openid authentication authorization) no context 8) scope:(openid authentication authorization) context="xxxx" ...........
-
This kind of use cases has been addressed by the User Questioning specification : http://openid.net/specs/openid-connect-user-questioning-api-1_0.html
Orange proposes to close this issue.
-
- changed status to closed
It was agreed to close this issue
- Log in to comment
based on the discussion regarding https://bitbucket.org/openid/mobile/issues/edit/1, the WG decided to factor our the authorization of a specific transaction to a new issue.