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

John Bradley ve7jtb at ve7jtb.com
Mon Nov 30 14:34:56 UTC 2015


I agree,  the problem is that m is that section might be taken to read that all login_token_hint values need to be in that format.   It needs to be clear that we are only talking about the format from the discovery service to the IdP.

John B.
> On Nov 30, 2015, at 5:23 AM, Lodderstedt, Torsten <t.lodderstedt at telekom.de> wrote:
> 
> 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,
> Torsten.
>  
> 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 <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 <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,
> Torsten.
> <draft-mobile-authentication-01_tlt.docx>_______________________________________________
> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20151130/ce9f4eda/attachment.html>


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