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

[Torsten Lodderstedt]

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?

section 4:

1st sentence "The service terms of service will specify ..." should this 
read "The service's terms of service will specify"?
2nd paragraph "This specification defines initial "acr" ... " why "initial"?
"IdP to make any guarente" - guarente -> guarantee
"business practices for account recovery, and customer service" remove 
comma?

http://schemas.openid.net/policies/mod/phishing-resistant - does mod 
stands for MODRNA? why not use modrna instead?

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?

"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.

"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).

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?

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.

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

section 10

protect eht user's MSISN -> protect the user's MSISDN

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