[Openid-specs-mobile-profile] Comments on draft-mobile-authentication-1

Lodderstedt, Torsten t.lodderstedt at telekom.de
Mon Nov 30 08:23:47 UTC 2015

Hi John,

login_token_hint is needed in the discovery case. There is no need to force any structure to the hint from account chooser. I would prefer to leave it opaque and specify another authentication request parameter.

best regards,

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von John Bradley
Gesendet: Sonntag, 29. November 2015 21:10
An: Torsten Lodderstedt
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] Comments on draft-mobile-authentication-1

No by policy I was referring to the GSMA privacy policy requiring the use of a discovery service rather than clients just asking for the users phone number directly.

I was thinking asymmetric from the discovery service to the IdP.
But give the IdP the flexibility on how they protect the tokens they put in account chooser for themselves.  Those could be symmetric.

So saying they must be signed and encrypted is probably the correct thing for the discovery service but not all tokens come from the discovery service.

John B.

On Nov 29, 2015, at 4:52 PM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:

If it is a policy decision, do we need to specify some way for the client to discover the OP's respective policy?
Regarding integrity protection: wouldn't that require a shared secret between discovery service and op? Not as easy to manage as an issuer url.
Am 29.11.2015 19:38 schrieb John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:
For login_hint_token,  The main reason to sign it is so that RP don’t start prompting users for phone numbers and creating there own tokens.
I can’t think of any security reason.

For an example of a signed and encrypted JWT see : https://tools.ietf.org/html/rfc7519#page-26  A.2.

It is more of a policy decision than a technical one to require signing.

We could require integrity protection instead.

That would let the discovery service sign and then encrypt.   The IdP could use a symmetric key to encrypt , and get sender verification in one operation.

John B.
On Nov 29, 2015, at 3:19 PM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:

Hi Jörg,

thanks for producing a new revision, which covers context and login_token_hint (@all: it's published at https://bitbucket.org/openid/mobile/raw/default/draft-mobile-authentication-01.txt).

Please find attached my comments as well as proposed text for security/privacy considerations sections and other aspects.

I would like to bring one question to the group's attention: Do we want to require the login_token_hint to be signed? What is the main reason? Issuer authenticity?

best regards,
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20151130/0eb5a4ca/attachment-0001.html>

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