[Openid-specs-mobile-profile] [User Questioning (a.k.a Transaction Authorization)] Second draft

Sebastian.Ebling at telekom.de Sebastian.Ebling at telekom.de
Wed Sep 21 16:59:30 UTC 2016


Hi all,

Thank you for updating the document Nicolas.

Here are my new remarks.

I would change the value "terminated" to "done" or "finished" for the status attribute of the User Statement Token (Section 2.2.). "terminated" sounds very destructive to me, but I’m not a native speaker and may be wrong.

I suggest to write "The Access Token obtained from an OAuth Authorization request MUST be
a Bearer Token. " instead of "The Access Token obtained from an OAuth Authorization request MUST be
sent as a Bearer Token.".
The access token is transient to the client, so the OP has to take care of a correct token for the requested scope/audience. I also recommend to define an explicit scope value for that service for better interoperability.

The Pulled-By-Client flow should have a poll rate. At least as suggestion for implementers. Polling in a loop without waits will be very resource intensive. 
For example: 
Polling SHOULD NOT start earlier than 3 seconds after User Questioning Request. The client then SHOULD NOT poll more than once a second.

Is there any security mechanism that protects the Client Notification Endpoint in the Pushed-To-Client flow from receiving a User Questioning Response from an attacker?
Of course, the id in the response object must be one that is known to the Client Notification endpoint. But I guess that will be not enough if the algorithm used to create the id is weak and proxies will log the id as part of the URL of PUT requests for the verification_code request from the client.
Of course, there are several options that could be discussed here. I start with: Sharing a secret in response of a User Questioning Request with a client_notification_endpoint and use of it for signing of the Questioning Response.


Formatting remark:
It is exhausting for me to read the document and get the point. I have no real suggestion for better structuring of the content at the moment. But reducing the depth of the structure by simply removing section headers for examples would be a good start to make it a bit easier at least for me.


Last and least, some typos:
“a End-User” -> „an End-User“
“to give his Statement“ -> “to give his statement”
„can be 2 3 4“ -> „can be 2, 3, 4“

Switch between “Access Token” and “access_token” in the document. I expect all appearances to be “Access Token” (OpenID style) or “access token” (OAuth style).

There are whitespaces in front of some punctuation marks.
For example:
„Mobile phone ,“ -> „Mobile phone,“ (whitespace before the comma)
“questioning context class reference :” -> “questioning context class reference:” (whitespace before colon)

Best Regards

Sebastian



Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von nicolas.aillery at orange.com
Gesendet: Montag, 19. September 2016 18:04
An: openid-specs-mobile-profile at lists.openid.net
Cc: VASSELET Mickaël IMT/OLN
Betreff: [Openid-specs-mobile-profile] [User Questioning (a.k.a Transaction Authorization)] Second draft

Hello Torsten, hello Sebastian,

   Here is an update of our draft.
   We tried to take your comments into account.
   We still have an issue with the ‘verification_code_flow’, because the enabled user interactions are required for Orange business and we cannot find a way to get it out of this specification,

Nicolas



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