[Openid-specs-mobile-profile] Initial Proposal
torsten at lodderstedt.net
Fri Sep 19 05:47:49 UTC 2014
<div>-------- Ursprüngliche Nachricht --------</div><div>Von: Nat Sakimura <sakimura at gmail.com> </div><div>Datum:19.09.2014 03:17 (GMT+01:00) </div><div>An: GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com> </div><div>Cc: torsten at lodderstedt.net, openid-specs-mobile-profile at lists.openid.net </div><div>Betreff: Re: [Openid-specs-mobile-profile] Initial Proposal </div><div>
I have created a repository for the WG.
Official path would be http://hg.openid.net/mobile/ but many glitches are there so for just working with the repo., I advise you to use the bitbucket hostname.
2014-09-17 2:55 GMT+09:00 GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>:
Sorry for the delay but I came back last week from my annual leave and I
have not found a free slot for this task until now.
First of all thanks to Torsten and Joerg for the initial proposal, it is a
very good point to start a discussion. I have sent all of you back the
proposal with my comments inside, in short I agree with the dynamic
registration process because it allows other OpenID providers to be
adhered without making changes in the RPs. However I don't think the
discovery process is the best for the particular case of the MNOs as
OpenID providers. The proposal shows that RPs are aware of the MSISDN
because they know it in advance or because they ask the user for it. And,
in this last case I reckon it breaks one of the properties of the OpenID
Connect that is to keep the user identifier hidden from the RPs.
I really think that if we consider offering the mobile identity
authentication as a single service (aka Mobile Connect) from the users
point of view, it is necessary to hide the topology of the service from
the RPs and make them believe that there is only a unique provider, we
should create this illusion. What I mean is that Google can offer its own
OIDC provider, Ping Identity, Microsoft or whohever can offer its own one,
but MNOs should offer only one (for all of them). So from my point of view
the discovery process as is defined in the "OpenID Connect Discovery"
document could be used to choose among one of the aforedmentioned, and in
case of choosing the "Mobile Connect" an internal discovery process must
be triggered once the user wants to be authenticated. I know that this is
something that is not easy to achieve with the current specs. but I think
that this is the appropiate forum to undertake this task.
I have written a proposal of a discovery process that I called "Implicit
Discovery" because it happens in the middle of an OpenID Connect
authentication request. Find attached this proposal that I want to share
with you to get your feedback on it and if you think it is feasible. It is
only an initial proposal that surely has some lack to be completed but I
think enough to have an idea of the concept to implicit discovery process.
Please let me know if you need further clarifications or more details on
any of the points raised.
El 12/09/14 10:40, "torsten at lodderstedt.net" <torsten at lodderstedt.net>
>if you haven't done yet, I would kindly ask you to read the proposal and
>post your comments to the list before our upcoming WG call (Sept 24th).
>This gives the other members an indication of your thoughts and helps me
>to prepare/organize the discussions.
>Thanks in Advance,
>Am 27.07.2014 20:14, schrieb Torsten Lodderstedt:
>> Hi all,
>> Deutsche Telekom has prepared an initial proposal for this working
>> group. Please find the document here:
>> The main purpose of this document is to facilitate the discusion
>> within the group about the challenges with have to cope with and the
>> assumptions we base our work upon. It also sketches a potential
>> solution (which is certainly open for discussions).
>> "See" you on Tuesday.
>> best regards,
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>Openid-specs-mobile-profile mailing list
>Openid-specs-mobile-profile at lists.openid.net
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile