[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.
Example:
{
"subject": "acct:joe at example.com",
"links":
[
{
"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
URL>/.well-known/openid-configuration).
Benefits:
+ 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,
Torsten.
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