[Openid-specs-mobile-profile] Mobile Profile WG Call Feb 22nd preliminary minutes
philippe.clement at orange.com
philippe.clement at orange.com
Fri Feb 24 14:46:59 UTC 2017
Please find below preliminary minutes of our call on Feb 22nd 2017.
In any case of error or misunderstanding, please let me know
James, john, Nicolas, Charles, Siva, Bjorn, Celestin, Keith, Axel
* Schedule for Implementers Draft
* Updates to Account Porting spec. (draft 04).
1. Schedule for Implementers Draft
Bjorn provides participants with the schedule for the MODRNA specifications ready for Implementer's Draft vote:
* Last call: 2017-02-22 to 2017-03-04
* Implementer's Draft Public Review: 2017-03-04 to 2017-04-18
* Implementer's Draft Voting Announcement: 2017-04-05
* Implementer's Draft Voting Period: 2017-04-12 to 2017-04-26
any comment or proposed changes to the schedule to feedback to Bjorn.
2. Updates to Account Porting spec. (draft 04).
distributed Feb. 13. [James]
Feedback from CPAS on Account Porting presentation. [James/Siva], updates proposed for next version
Request is done to everybody to review last specs 0.4.
3. Discussion on asynchronous /synchronous modes and user consent/authentication for token retrieval
Question to Siva about CPAS discussions.--> Siva to send CPAS minutes
* CPAS inclined to develop a formal spec and combine the different options as a single proposal and then align with MODRNA.
* Questions on the call: more than choosing asynchronous versus synchronous modes, does the OP retrieve user consent, and authenticate the user ?
Following a question of the call on the process, a remark from MODRNA chairman regarding CPAS decision: making specs in CPAS before providing them to MODRNA seems not the good order for operations.
* Telefonica already implemented in UK. Axel to get in touch with them.
* Question regarding TSP collecting consent from user. On what ID ?
* Attention to confusion regarding different use cases: In any case, good to know who captures the consent and authenticates the user.
Do we have a good understanding of "what is a trusted SP", and what are the use cases applying in this case ?
The use of CIBA without authentication nor consent may not be relevant and a refresh_token mechanism may probably be preferable.
* John advice is to not rewrite specs if some existing ones can do the job. In case of trusted provider, deliver a refresh token for offline access is a recommendation.
* An additional scope offline could solve later access from RP to OP without prompting user.
* Siva suggests to take back to the CPAS the use of the refresh token. In this case, User has been previously authenticated by OP.
* Authentication by the TSP seems not a good idea, how to know it's the right user identified by SP ?
* Talking of UK UC. Ex: Trust Equifax to provide attributes. JWT assertion with a signature "give me attributes towards this identifier" has nothing to do with OIDC.
* John: need for separating APIs in order for people to not confuse them.
* Question on User Experience impact.
* Axel: separating between design and other is bad for privacy and other concepts of OIDC. MC changing the architecture could lead to undesirable outcomes.
A good approach should be to get the consent at one time, and then deliver a refresh token for the TSP to come back later to OP for getting access token and ID token for access to user resources.
We have to post these concerns on CPAS immediately.
* Bjorn: regarding the process, GSMA must provide Use cases to MODRNA for them to propose solutions. The problem seems to rely on multiple variations of use cases. Siva mentions a presentation of David Pollington, to provide to MODRNA list.
Once use cases presented, MODRNA provides tech guidance. Having the same discussions in 2 different bodies is not the good approach.
a common work between MODRNA and CPAs is a prerequisite for headways.
4. News from the may workshop
location: we have support from Verizon in Netherlands
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile