[Openid-specs-mobile-profile] Technical Workshop CPAS/MODRNA on Mobile Connect
Torsten.Lodderstedt at telekom.de
Torsten.Lodderstedt at telekom.de
Sun Oct 9 15:26:45 UTC 2016
please find below the preliminary minutes of the joined workshop in Paris for your feedback.
Minutes of the joined Workshop on Mobile Connect between GSMA (CPAS project) and OpenID Foundation (MODRNA WG)
Date: 27/28th of Sept 2016
Location: Orange Gardens, Paris, France
* Philippe Clement (Orange)
* Mickaël Vasselet (Orange) (27.9)
* Nicolas Aillery (Orange)
* Charles Marais (Orange)
* Gautam Hazari (GSMA)
* Venkatasivakumar Boyalakuntla (GSMA)
* John Bradley (Ping Identity/OIDF)
* Gonzalo Fernandez Rodriguez (Telefonica)
* Arne Georg Gleditsch (Telenor Digital)
* Keith Uber (Globalsign)
* Petteri Stenius (Globalsign)
* Bjorn Hjelm (Verizon Wireless)
* Sharam Mohajeri (AT&T)
* Florian Walter (Deutsche Telekom)
* Jörg Connotte (Deutsche Telekom)
* Torsten Lodderstedt (Deutsche Telekom/OIDF)
<please give feedback, I unfortunately did not keep track of remote attendence>
Note: AI indicate Action Items, D denote Decisions
- James presented the current draft
- representation of multi step migrations
-- either embedded JWTs (draft-account-migration) or pointer in the additional aka member of the porting data (draft-account-porting)
-- if an OP goes out of business, the trust chain breaks
-- user needs to setup access to account again
-- push notification to trigger prompt migration? (conclusion: complex to implement, privacy implications needs to be considered carefully)
- how is the step (1) of migration process initiated? Examples: self care or part of mobile connect registration process
- what happens after migration? does the OP still serve the account?
-- moving vs linking new OP (and retain old one)
-- both possible from technical perspective
-- Mobile Connect has special requirements around Mobile Connect account lifecycle
-- moving means removing all data at old OP
- how to indicate successful move of responsibility?
-- move is indicated by first successful porting on any RP
-- old OP may server requests for the account being moved as long as the first porting did not happen
-- observation: old OP needs anyway to retain old data to serve API, could cause privacy issues, which could be solved by asking for user consent during initial migration to new
-- yet to be decided: will the spec support move only?
AI: get consensus on move vs linking (Torsten)
- if the OP is no longer responsible, there needs to be an error code indicating the change to the RP - no longer responsible, please discover again
D: goes to IANA section of porting spec
- authentication at the port check endpoint?
- reasons: allow old OP to unambiguous identify RP and determine respective subject value
D: authenticate RP at old OP
Discussion over lunch (John, Arne, Torsten)
- potential privacy issue: RPs could try to correlate PPIDs by using porting token in conjunction with different client ids
- challenge: client ids are different with old and new OP, how could old OP detect such an attempt
- assumption: host of sector id (or redirect_uri) is common denominator/shared data among the OPs
- idea: put sector id/redirect_uri into porting token that way making the porting token RP bound, old OP checks host parts for equivalence
Alternative shared data:
- software id (requires dynamic registration)
- RPs public key (requires assertion-based client authentication)
User Questioning aka UQ (Nicolas, Charles)
- Utilizes the OPs authentication capabilities and the user's credentials and establishes a secured channel to the user to gather user's consent or confirmation or approval
- There are 2 usages for the User Questioning API: instantly consuming the response (and possibility forget it) or archiving the response (and possibly use it at several moments). When archiving, non-repudiation is an important feature.
- Difference to general purpose messaging API: The GSMA OneAPI enables a Service provider to send SMS or MMS to users. It also enables a Service Provider to subscribe to messages send back by users. This is a general purpose messaging API for one-way notifications, not a questioning API where the response has to be bound to the question to be meaningful. Besides, the messages are not signed by the MNO.
- user id representation: access token OR MSISDN as parameter
-- alternative options: always use access token, which can also be obtained by using the assertion flow + user id
- User Statement Token
- what is the difference between qcr and acr? is it questioning_acr? seems to need more explanation
- claims in JWT differ from ID token by statement and question only
- contains MSISDN in some cases but no sub (OP-provided stable user id)
- D: sub shall be contained in every user statement token
- fold together with backchannel authentication? discussion postponed to Wednesday
- best poll rate?
-- same challenge for backchannel authentication, question and device flow - should discuss with other players in the OAuth WG
-- idea: long polling
- what is being displayed? RP provided text or more?
D: MSISDN shall be part of the user statement in order to mirror request parameters
D: "terminated by client" will be removed from the spec as proposed by the authors
- discussing about enhanced semantics of the UQ
-- Accept/ Deny has poor semantics
-- customizing buttons
-- multi-value answers
-- open questions
D: Stick to simple accept/deny for now (keep it simple)
-- recommendation should be to always use closed questions with UQ
- finding from Wednesday session: it might be a good idea to have a cancel/esc option on the screen, if the user does not want to answer the question (e.g. unsolicited request) -> requires dedicated return/error codes
Server-initiated Back-channel Authentication aka SIBA (Gonzalo, Florian)
- request/response names need to be more expressive
- same holds true for new endpoint name
- determining push or pull? transaction-based, client policy, ?
D: based on client policy (simple, sufficient, secure, capacity management) -> also relevant for UQ
- shall the OP always support push?
--> no decision yet
- request parameters - body or JSON (consistency vs better solution)
D: JSON for all new endpoints the WG defines - also relevant for UQ
- one or multiple push notification URLs?
D: single URL sufficient
AI: align with other new specs regarding JSON requests, e.g. Device Flow (A: John, Torsten)
- PremiumInfo/UserInfo in Mobile Connect Profile (Siva)
-- do we need a concept to represent claim validation quality?
--- syntax: how to represent it? JSON object, # syntax ...
--- data: which data?
--- semantics: what is the meaning? or leave interpretation up to RP
-- Syntax: other claim names for representing validated claim values, (2) additional flag claim, (3) meta data representation for claims
D: option 3 is preferred
-- UserInfo vs. PremiumInfo
R: recommendations of the WG and operator representatives to CPAS: use user info, either define OIDC claims or use collision resistent claim names for MC specific claims
- Authorization of Callback Requests (for SIBA but relevant for UQ as well)
-- different options for authorizing the callback from OP to client to deliver authentication transaction result have been discussed
0) Use client credentials from registration time (state optional, auth_req_id)
1) auth_req_id is authorization token (state optional)
2) client-generated access token (one time use/opaque to OP), BEARER header used in callback (state ?, auth_requ_id ?)
3) state parameter is used as authorization token (state mandatory, auth_req_id mandatory)
4) authorization code sent to callback, client uses code to obtain tokens from OP's token endpoint
D: 2 or 4 will be further investigated
Note: 4 seems to be vulnerable to mix-up (alike) attacks (see https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01) - both options need to be investigated from a security perspective
AI: description of II and IIII is added to SIBA spec along with pros and cons (Florian, Gonzalo, Petteri)
- binding message (authn profile spec)
AI: reconsider binding_message parameter (purpose, semantics, ...) (Jörg, John)
- Convergence between User Questioning, server-initiated backchannel authentication, device flow (WG)
-- discussed differences between SIBA and UQ approaches (independent of the technical solution)
-- SIBA: OP enforces policy (by way of issuing access tokens, which contain authz data)
-- UQ: OP links user to policy, RP enforces policy
-- ID token in a middle ground between SIBA and UQ since it (1) does not directly enforce a policy but rather provides data for doing so the the RP and can be used to (2) provide authz data to the RP
- "User Questioning" (UQ) and "Server Initiated Backchannel Authentication" (SIBA) can address similar high level use cases. The main difference is the entity that takes the responsibility of protecting the resource. In SIBA, the OP is the Policy Decision Point (PDP) and the RS is the Policy Enforcement Point (PEP). In UQ, the Client is both the PDP and PEP. The OP exposing the User Questioning API is only responsible of questioning the good person (sending the question to the good person) and capturing his statement (getting his answer).
D: continue to work on both approaches separately
AI: authors add explanation of the properties of the approaches to respective specs (Nicolas, Charles, Gonzalo, Florian)
D: WG will discuss ways to converge technical solutions later on, when both specs have stabilized (drivers: might be a challenge to explain to RPs why there are two different approaches and when to use what, users will most likely not recognize any difference when it comes to the UX, RP may want to use both approaches in combination - two independent solutions would require two separate user interactions)
- Alignment of ACR representation (vectors of trust)
-- John presented the status of the current work at NIST and eGov
AI: review documents and give feedback (WG)
AI: John to post relevant links on the list
- Based on the workshop discussions, UQ will be modified as follows
- Removal of the Client-Terminated-Flow (a.k.a SMS OTP flow)
- JSON format replace urlencode format
- One endpoint for User Questioning Request, another for Polling
- In User Questioning Request
- New attributes: client_notification_token (optional), possible_statements (optional array)
- Removed attributes: client_notification_endpoint
- In User Questioning Response
- The Client will be using either Polling or Client Notification, not both.
- For Client Notification, the client_notification_endpoint is registered at registration
- New error: "user_refused_to_answer" (interactions and error managed by the OP)
- The User Statement Token always contains the iss, aud, sub
- The User Statement Token contains the user_id / user_id_type if they were in the request (in order to mirror the request)
- Enabling polling and long polling in the same flow respecting both OP and Client contraints
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile