[Openid-specs-mobile-profile] Client credential lifecycle mgmt for Native Apps
torsten at lodderstedt.net
Mon Apr 13 09:29:45 UTC 2015
interesting comment. So far I assumed the service provider would need to sign Terms of Service for every MNO and the MNOs the SP had signed up for would be carried in the software statement.
Mapping this to your use case would mean to issue and roll out a new software statement - so no benefit with respect to this use case.
Am 13. April 2015 11:03:03 MESZ, schrieb GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>:
>I don't have a clear preference on which is the best option, however I
>see another "pro" in the second one, I think it offers a smooth
>integration in case of a new operator is on boarded in Mobile Connect
>because is transparent for the Service Providers. If a user that
>belongs to the new operator is going to be authenticated, once the
>operator is discovered, the Service Provider would only have to send a
>registration request without needing to be aware if the operator is new
>or not in Mobile Connect. I don't know how could manage this scenario
>using the first approach.
>De: <Lodderstedt>, Torsten
><t.lodderstedt at telekom.de<mailto:t.lodderstedt at telekom.de>>
>Fecha: viernes 10 de abril de 2015 18:39
>"openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>"
><openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
>Asunto: [Openid-specs-mobile-profile] Client credential lifecycle mgmt
>for Native Apps
>during the working session at IIW it became apparent that we don't have
>a consent on the way client credentials are managed for native apps in
>the context of the mobile profile. As this an important design
>consideration, which will drive not only the registration spec but also
>considerations with respect to signature algorithms and so on, I would
>like to come to a consensus on that topic soon.
>There are basically two options:
>1) All instances of a native app (== the software package) share
>the same identity. This typically means, the app is registered as a
>so-called public client with the AS/OP and only gets issued a
>client_id. In the context of the mobile profile, I would assume the
>developer registers with a developer portal and gets issued distinct
>client_ids per MNO (a pair of issuer and client_id). At runtime, the
>app can decide based on the outcome of the discovery process which
>client_id to use for the respective MNO.
>2) Every instance of a native app on a device is registered with
>the MNO. This would typically happen when the user uses the login with
>a certain MNO on this device for the first time. So the app first would
>discover the MNO and determine whether it already is in possession of
>client credentials for this particular MNO (based on its Issuer). If
>not, it would send a registration request to the MNO.
>I see the following pros and cons:
>Option (1) is established practice (except the fact an app managing
>several client ids for different OPs). So developers know how to work
>that way. Software statements could be used to automate the way client
>ids are obtain in the deployment process. But there are other ways as
>Option (2) is a new approach. It has the advantage to provide every
>instance with a distinct credential, which allows to recognize and
>authenticate this instance later on. It could be used to prevent authz
>code theft on the device, something we already have SPOP for
>(http://tools.ietf.org/html/draft-ietf-oauth-spop-10 - sorry John,
>forgot the new acronym). Do you see other advantages? On the other
>hand, this option would require the OP to implement credential
>management for potentially a lot of client instances. This will be a
>challenge with respect to state management on the OP's side.
>Please comment on this topic.
>Thanks in Advance,
>DEUTSCHE TELEKOM AG
>Products & Innovation
>Dr.-Ing. Torsten Lodderstedt
>Head of Development
>T-Online Allee 1, 64295 Darmstadt
>+49 6151 680 7038 (Tel.)
>E-Mail: t.lodderstedt at telekom.de<mailto:t.lodderstedt at telekom.de>
>ERLEBEN, WAS VERBINDET.
>Die gesetzlichen Pflichtangaben finden Sie unter:
>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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile