[Openid-specs-mobile-profile] Initial Proposal

Connotte, Joerg j.connotte at telekom.de
Tue Jul 29 09:02:17 UTC 2014


Hi Tim,

I’ll try to explain some of our assumptions leading to the proposal

Von: openid-specs-mobile-profile-bounces at lists.openid.net [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Tim Bray
Gesendet: Montag, 28. Juli 2014 03:41
An: Torsten Lodderstedt
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] Initial Proposal

First of all, excellent start!  Thnks to Torsten and his DG colleagues.
==========================
Section 3.2: “The RP shall register to a certain MNO or another entity MNOs delegated this task to once and obtain the right to access the desired MNOs’ ID services. To enable this autonomy of relying parties and OpenID Providers (the MNO‘s) dynamic client registration must be possible.”

Why?  I’m in favor of dynamic registration, but in the typical use case, suppose I’m an RP, I want to register an app with TMO and have it work on Orange, why is a traditional RP registration process with TMO not possible?
JCO:  Maybe the phrasing wasn’t to good here. What we are getting at is that the RP registers traditionally with TMO (probably signing some contract). The operator performing this initial registration is called the Developer Operator. After that the process of registering the RP with Orange and possibly dozens or even hundreds of other  MNO’s which each facilitate their own OpenID Provider should be done automatically. Thus using dynamic client registration seems to be the way to register to the subsequent OIDP’s (called serving operator).

==========================
A little worried about the software statement in a public client, where it can be easily stolen; not sure I understand what it accomplishes.
JCO: The software statement can at least reflect the fact that the initial registration of the RP was done properly. Depending on the content of the software statement the OpenID Provider will be able to reject the RP based on a blacklist published by the Developer Operator.
==========================
It would be more readable if the references were by title not by name, e.g. “OIDC Discovery” rather than ”[3]”
==========================
Section 4: This is all about web apps, and I see that there’s value-add in defining an advanced discovery process that can return an OP to support a standard OIDC flow, where the OP is doesn’t depend on which telco the RP registered with…  Do we have any ambition to support the native-app case?  That’s where the real developer pain is.
JCO: I certainly think the native app case should also be discussed. We wanted the example flow to stick as closely to the standard OIDC flows as possible.

===========================
Section 4. “In this example, the RP is a web application, which asked the user to enter his msisdn”. Ideally, it should be possible for the software to get the identifier from the phone hardware?
JCO: The way the msisdn is obtained may vary depending on the user agent. Not all operating systems on mobile devices allow for the retrieval of the msisdn programmatically. Sometimes only MNC and MCC are possible. However one valid use case is that the user agent is a browser on a pc client. In this case the user has to enter his/her msisdn manually.
===========================
Generally, I was hoping there to be some back-channel magic that would be enabled by involvement of GSMA members.  The SIM or equivalent already constitutes some sort of an identity assertion so I’d hope that could be used, for example simplify discovery.  Any chances?
JCO: There should be any number of different ‚resource‘  types for discovery. MCC/MNC or mobile ip-address come to mind. Those can be either retrieved by the client or extracted from the header information by the operator discovery service. In those cases no user interaction is required for discovery.

Regards
Jörg
On Sun, Jul 27, 2014 at 12:33 PM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:
Hi Tim,

why don't you just post your comments here?

regards,
Torsten.

Am 27.07.2014 um 21:08 schrieb Tim Bray <tbray at textuality.com<mailto:tbray at textuality.com>>:
Thanks! I started reading this and immediately had a couple of comments I wanted to make.  Perhaps this could migrate into a comment-friendly form like a wiki or Google doc or something soon?

On Sun, Jul 27, 2014 at 11:14 AM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:
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<mailto:Openid-specs-mobile-profile at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile



--
- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)



--
- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20140729/7a918df8/attachment-0001.html>


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