[Openid-specs-mobile-profile] Initial Proposal

Torsten Lodderstedt torsten at lodderstedt.net
Sun Sep 21 15:36:59 UTC 2014

Hi Gonzalo,

thanks for your comments (and your proposal).

I would like to start with your comments regarding the initial proposal 
from DT.

 >Which component/entity would be in charge to call this normalization 
service? I don't think the RP is the best option in case of using the 
MSISDN because we must able to use the authentication service in case of 
 >the RP doesn't know the user's msisdn and without needing to ask him 
for it.

Yes, it is the RP that uses the discovery/normalization. This holds true 
in all cases where the RP can get hold of network/subscription data 
suitable for discovery. The RP could also directly ask the user for her 
MNO. I understand your concerns regarding acquiring the MSISDN by the RP 
- see my comments below.

 >Is it also assumed somehow of enrollment before being registered in 
the first OpenID provider/MNO? in order to get the sw statement and to 
agree the T&C?

Not sure what you mean. The RP is assumed to go through an approval 
process before it is actually issued a software statement. So the 
software statement is one of the results of this process (assuming there 
will also be commercial/legal artifacts).

Step 1.4:
 >If it means the RP needs to know the MSISDN I guess that it 
invalidates one of the main reasons to use OpenID Connect that is to be 
able to authenticate a user without needing to know its MSISDN. So if we 
 >need to know it to get the OpenID provider in the discovery process....

see below

Step 1.7:
 >Same reason as before, the OpenID provider, in this case the MNO must 
not share the MSISDN. I guess the idea is to use it in the "login_hint" 
but i think that is not the way to do that, we would need the subject 
 >identifier as is defined in the OpenID Connect 1.0 core spec.

Thanks for your advice. Passing the MSISDN to the OP via the login_hint 
is a good idea.

The description you refer to in your comment is not intended to function 
as login hint but follows the mechanics defined by OpenID Connect 
Discovery. If a RP sends a discovery request to the web finger service 
using a certain resource identifier, such as an email address, this 
resource is reflected in the corresponding web finger response.

    "subject": "acct:joe at example.com",
       "rel": "http://openid.net/specs/connect/1.0/issuer",
       "href": "https://server.example.com"

------------------------------------ your proposal 

Your proposal raises two important questions I would encourage the 
working group to discuss: (1) what about the privacy of the MSISDN and 
(2) act all MNOs autonomously or as a single IDP (from the RP's 
perspective)? I would suggest to put those questions to the agenda of 
our conf call.

1) The current proposal assumes the MSISDN (beside other options such as 
MNC/MCC or IP addresses) is used to discover the MNO's OP. This means 
the RP gets to know the MSISDN, an information we probably want to 
protect from the RP.  Basically, I understand your concern. Please not 
this approach (to use a user know identifier to lookup the OP) is 
inherited from standard OIDC discovery. Do you/we see an issue there as 
well, e.g. regarding the disclosure of email addresses?

You propose to let a trustworthy intermediary collect the data and 
perform discovery. As far as I understand the flow, this discovery 
process is part of the authz code flow.
- How is this approach supposed to work for other grant types, such as 
refresh token?

I personally see the benefit of the approach you propose, but I don't 
think the discovery should be merged into the actual authz/authn flow. 
The discovery service could by a complementary component of the web 
finger service and return the issuer URL as result of the discovery 
process (instead of directly redirecting to an MNO). The RP can then 
obtain OP metadata in standard OIDC fashion (via <issuer 
+ this approauch would work for all grant types
+ it clearly distinguishes responsibility of the central discovery 
service and any MNO's OP service

What do you think?

2) Act MNOs autonomously or as a single IDP?

 >"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)."

I would like to know why Google shall be an autonomous IDP but MNOs as 
separate legal and commercial entities (and brands) should not?

Yes, with the current proposal, every MNO may act as an autonomous IDP. 
This means developers/RPs see and need to understand existence of 
different OPs (per MNO). Your proposal is to hide (all?) MNOs behind a  
facade, which is exposed as a OAuth/OIDC authorization endpoint.

My comments:
- The MNOs are only partially hidden since token and user info endpoint 
are directly accessed (for good reasons :-))
- The proposal also requires an extension to the base OIDC flow (at 
least new parameters to return an issuer URL or endpoint URLs)
- How is it supposed to work with other grant types than authz code?
- Which client_id does the RP use? How does it obtain and select it? 
Which parties know which client credentials?
minor details:
- step 4: I don't think there is a need for a service directory. The 
discovery system should use OIDC discovery to obtain MNO endpoint data.
- step 5: What is the purpose of the cookies? User id can be passed 
using login_hint parameter
- step 8: MNO also may use other user ids

best regards,

Am 16.09.2014 19:55, schrieb GONZALO FERNANDEZ RODRIGUEZ:
> Hi guys,
> 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.
> Best,
> Gonza.
> El 12/09/14 10:40, "torsten at lodderstedt.net" <torsten at lodderstedt.net>
> escribió:
>> Hi all,
>> 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,
>> Torsten.
>> 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:
>>> http://openid.bitbucket.org/Mobile_Profile_initial_draft_016.pdf
>>> 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,
>>> Torsten.
>>> _______________________________________________
>>> Openid-specs-mobile-profile mailing list
>>> Openid-specs-mobile-profile at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> ________________________________
> 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

More information about the Openid-specs-mobile-profile mailing list