[Openid-specs-mobile-profile] OpenID Connect Mobile Profile WG Call: preliminary notes 25 02 15

[philippe.clement at orange.com]

Dear all,
Please find below the preliminary notes of our call. Please let me know of any error or missing element.

Participants:
Gonzalo Fernandez, Telefonica
Torsten Lodderstedt, Deutsche Telekom
Jörg Connotte, Deutsche Telekom
John Bradley, Ping Identity
Philippe Clément, Orange
Björn Hjelm

Agenda:
1-      Document status
2-      Basic assumptions for registration (Björn)
3-      Sub claim persistence in case of portability

Discussions:
1-      Document status
Discovery specs: Work with AC team still on track (John).
Torsten remarks will be introduced and structure of the doc rearranged
==>     next version of the document to be provided by next week

2-      Basic assumptions for registration (Björn)
a.      Trustworthiness of an RP
         This trustworthiness can be done at 2 different phases, first in enrolment, second in the time of RP request
         It would be difficult to align all operators on the same rules, as probably legal and contractual conditions will differ from an operator to another.
         Remains the fact that a serving operator is different of a developer operator carrying the contract. More than this, in the European legal framework, an operator could be responsible for usage that an RP made of user data, without carrying the contractual/legal relation.
b.      How to block an RP
         An IdP has the ability to reject a RP request. The question relying on how the serving operator knows that this RP has to be blocked is OOS.
c.      Claims to be used in the software statement
         List to be defined and discussed. Some examples: Identifier, redirect URI, asymmetric or public keys...

==>     Björn to write a first draft of the document and insert remaining questions directly inside, to be discussed on the mailing list

3-      "Sub" claim persistence in case of portability (Gonzalo)
   Main concern exposed by Gonzalo: when a user having an account on an RP churns from an operator to another, the sub (identifying the subject=user) towards the RP changes, due to the fact that it's another operator to authenticate user, this second operator having a different way to produce the sub.
   This will lead for the RP to an impossibility to link the new sub (provided by operator2) to the former sub (provided by operator1)

   First level of answer is that this concern should be endorsed by operators.
   Remark: the former sub at operator1 can continue to exist and be provided to RP unless account management.

   The risk to have the same reference for 2 different users at an RP doesn't exist in OpenID Connect, since the tuple sub-issuer is unique.

   A strong advice for an operator: to have an unchanging identifier (sub) for a user attached to the account, and not dependent of any dynamic user information (like MSISDN)


Kind regards,
Philippe


_________________________________________________________________________________________________________________________

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.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150225/bac63ed0/attachment.html>