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

[Lodderstedt, Torsten]

Resending on behalf of Philippe :)

Von: philippe.clement at orange.com [mailto:philippe.clement at orange.com]
Gesendet: Mittwoch, 13. Januar 2016 15:32
An: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net; John Bradley; Connotte, Joerg
Betreff: RE: [Openid-specs-mobile-profile] Comments on draft-mobile-authentication-01.txt

Dear John, Joerg and Torsten,

Some minor typos encountered:

Abstract, line 29: "messge" to be replaced by "message"

3- Authentication request,

è  line 131: "paramaters" to be changed into "parameters"

è Line 134: acr_values REQUIRED

o   It Could be interesting to define somewhere what a "MODRNA conform authentication request" is

4- ACR values request values and level of assurance

è Line 220: may be interesting to write in full text what a EKG band is. (I presume it's an electrocardiogram device?)

è Line 241: in "the requested acr valued", replace with "the requested acr value"

5.1- AMR Value Examples
-->  line 317: remove ":" in "note: that"

6- login_hint_token

è Line 355: "the users OpenID Provider" or "the user's OpenID Provider"

6.1 login_hint_token encryption and signing
--> Line 381: is it "/.well-kown" or "/.well-known" ?

7 binding_message

è Line 413: when speaking of "The context", are we speaking of something different from the binding_message ? (context also mentioned in lines 434, 438)

10 privacy considerations

è Line 459: replace "eth" by "the"

Hope this helps...

Kind regards,
Philippe

De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Lodderstedt, Torsten
Envoyé : lundi 11 janvier 2016 11:41
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; John Bradley; Connotte, Joerg
Objet : [Openid-specs-mobile-profile] Comments on draft-mobile-authentication-01.txt

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.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160113/66b0bbc4/attachment-0001.html>