[Openid-specs-mobile-profile] updates to authentication

John Bradley ve7jtb at ve7jtb.com
Sun Dec 13 20:44:44 UTC 2015


OK I will work on those edits on the flight.

Inline
> On Dec 13, 2015, at 2:29 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> Hi John,
> 
> here are my comments:
> 
> section 3: context - in the call on 2.12, we decided to accept GSMA's inquiry and change the parameter name to "binding_message". Can you please change it?

OK
> 
> section 4:
> 
> 1st sentence "The service terms of service will specify ..." should this read "The service's terms of service will specify”?
OK
> 2nd paragraph "This specification defines initial "acr" ... " why "initial”?
We might add others later, such as ones that include identity proofing.
> "IdP to make any guarente" - guarente -> guarantee
> "business practices for account recovery, and customer service" remove comma?
OK
> 
> http://schemas.openid.net/policies/mod/phishing-resistant - does mod stands for MODRNA? why not use modrna instead?

To try and keep the length down, remember the requested list is passed in a query parameter.  Too long and we start blowing up browsers for the 302 request.
> 
> mod-mfp - the only difference between mod-mfp and mod-mf is that mod-mfp allows biometry only as proof of user presence. Why do we need this additional level?

I wanted to have it as an example for you to ask to be taken out:)   Better to discuss it and take it out so that when someone asks for it later we have a response.  
Mostly the Biometric people will want it.

> 
> "Identity Providers MUST recognize and process both the long URI and   short registered forms of the authentication context strings." Why two options if one is sufficient? I would opt for the URI form because it ensures uniquness of the value across profiles.
> 
It is a size issue, using the short name may prevent the request from getting to large.  If we do only one I would go for short.

> "The OP MUST also support receiving "acr" as a as a claim request in a
>   signed request per OpenID Connect Core 5.5.1 [OpenID.Core]." I think we need to point out why this is required. As far as I understand, this is the only way to force the OP to comply to the requested acr values (and the respective policies).

Yes it is the only way to force the OP to error out if one can not be met.   I used to think that was important but people have successfully argued that the RP needs to validate the response anyway, and it is better to have it generate the error as it is more likely to be able to help the user or offer reduced access.   The IdP generating a error is mostly useful for really stupid clients, and requires a signed request so it cant be tampered with.
> 
> section 5:
> 
> What's the overlap with https://tools.ietf.org/html/draft-jones-oauth-amr-values-02? Should we base our amr value on this spec?

That we are discussing with Mike on Monday.  I have proposed adding PIN to his doc.

That doc establishes a registry and is extendable.   I think Mike and Phil picked some inital values that they though were reasonable.
However I don’t know what “mfa” or “rba” would mean on there own as they are general concepts.   

To be discussed Monday.

> 
> section 6:
> 
> As far as I remember, we decided to relax the format constraints on the login_hint_token parameter in order to support its use for interchange between different entities (e.g. discovery service and OP) as well as OP specific use cases. I would recommend to spell this out in the first paragraph (instead of just having a note towards the end of section 6.1.
> 
> proposed text:
> The "login_hint_token" is used to pass a user hint into the authentication process at the OP. This hint is opaque to the client by design.
> There are several ways for a client to obtain a login hint token. To start with, the MODRNA discovery services creates such a
> hint if the user has entered her MSISDN in the course of the MNO discovery process. In this case, the login hint token is supposed to be a
> signed and encrypted JWT. The Authorization server may produce "login_hint_token" tokens in other formats for use in Account Chooser
> or other discovery profiles, as long as they are confidentiality protected from the client.
> 
OK

> section 9
> injedtion -> injection
> 
> I would suggest to add to the first paragraph: The signature allows the OP to authenicate and authorize the sender of the hint and
> prevent collecting of phone numbers by rogue clients
> 
OK
> section 10
> 
> protect eht user's MSISN -> protect the user's MSISDN
> 
OK
> best regards,
> Torsten.
> 
> 
> Am 13.12.2015 um 18:28 schrieb John Bradley:
>> I merged in some editorial changes by Axil,  and added a bit more amr text for people to review.
>> 
>> I am waiting for comments.  It is hard to believe all the new text I added is perfect.
>> 
>> John B.
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> 



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