[Openid-specs-mobile-profile] Comments on draft-mobile-authentication-01.txt

[Lodderstedt, Torsten]

Hi John and Jörg,

here are my comments on the latest revision of your draft:


-          §4

o   3rd paragraph: guarente -> guarantee

o   "Identity Providers MUST recognize and process both the long URI and short registered forms of the authentication context strings." - why do we need both forms? Isn't the long form sufficient?

o   "The OP MUST support receiving "acr" as a as a claim request in a signed request per OpenID Connect Core 5.5.1 [OpenID.Core]."

§  pls. remove one "as a"

§  doesn't turn this claim parameter into MTI?

o   "This  method prevents the request from being modified by the user, and allows the requested "acr" valued to be considered essential claims causing the IdP to respond with an authentication error if no requested "acr" value can be fulfilled."  - I perceive two different requirements in this sentence:

§  Prevent modification of the request - I would consider this a general requirement, which should be addressed in a general section (e.g. security considerations)

§  Making the acr value an essential claim causes a different behavior of OP and RP. As you mentioned, the OP will fail instead of trying to authenticate the user in a best effort manner. Is the RP nevertheless supposed to validate the acr value in the result of the authentication transaction? I think we need to specify the expected behavior of the RP in both cases (request parameter and essential claim).

-          §5

o   Are those amr values mutual exclusive? I'm asking because "user" sounds very generic. Isn't the intention of any authentication method to prove presence of the user?

-          §5.1

o   "If the authentication is by sending .." something is missing here, "performed"?

-          §6

o   "TBD:" - that's all standard OIDC stuff - I think it will be sufficient to refer to OIDC discovery and additionally give an example.

-          §6.1

o   "The login_hint token MUST be signed using the private key of the Discovery Service." - Is our assumption that the public key of the discovery service is well known to the OP (e.g. exchanged oob)? In contrast, section 6 refers to 6.1 for an explanation of the key discovery process??

o   "It is best practice to sign then encrypt tokens, as signatures over encrypted information may leak information in the envelope, and may not be considered legally valid." - I think in order to achieve interop this text needs to clearly specify the order of signature and encryption.

o   "Note: " redundant to §6, 3rd paragraph  "The Authorization server may produce "login_hint_token" tokens in  other formats for use in ccount Chooser or other discovery profiles, as long as they are confidentiality protected from the client."

I would like to discuss in our next call whether we include the counter measures against confused client state and code injection into the first version of this spec in order to ensure an adequate security level until the respective OAuth drafts will be available.

Best regards,
Torsten.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160111/2b2dc945/attachment.html>