[Openid-specs-mobile-profile] [User Questioning API] Fourth draft

[Torsten.Lodderstedt at telekom.de]

Hi Nicolas,

thanks for publishing the new revision. Here are my comments:


-          Introduction

o   "This specification defines a specific endpoint" - Your spec basically defines three endpoints, defined in sections 7.1, 7.2, and 7.3.

o   "The way the Access Token has been obtained by the Client is out of scope of this specification." This statement appears "out of the blue". I think it is better moved to the respective endpoint/request description - in this case User Questioning Request (I assume).

o   I would generally recommend you give a more general introduction to the topic in order to help the reader to understand the problem, which is being solved, and the way it will be solved. This might incorporate to describe the use cases and the different modes of UQ. Potentially, you should merge the text from 1 and 2 and give an architectural overview (different endpoints) in 2

o   You should also mention that there is a user statement, which is a digital signed policy.

-          Section 3

o   I think there is more text required to clearly differentiate sub and user_id. I know the differences but I cannot find the respective explanation.

o   "The signature MUST be a digital signature." I think the previous already covered this requirement.

o   "Message Authentication Codes (MACs) are FORBIDDEN." Why?

-          Section 4

o   What do you mean by "reachability identifier"?

o   I think Section 4 should become a sub-section of Section 7 as the topic is related to the User Question Request.

-          Section 6

o   I think this Section should become Section 2 because it gives an overview on the different interaction patterns and respective endpoints.

-          Section 7.1

o   What is the purpose of this endpoint?

-          Section 7.1.1.

o   "The Client MUST have a valid Access Token for the scope question." - I suggest to mention the access token may refer to the user, which shall be questioned, and a reference to the general user id discussion.

-          Section 7.1.2

o   I still don't buy use of response headers to inform the client of the question_id and the location of the polling endpoint. It is also incompliant with the way the respective data are returned in the SIBA spec. I think we should try to use the same patterns if possible.

o   I also fail to see the advantage of a dynamically advertised polling URL. A static URL would do the job as well.

o   As we are planning to move to implementers draft, I would like to ask the group for an explicit decision regarding these points. Fine with you?

-          Section 7.2.3

o   Why not just title "Successful Polling Response"?

o   Why is the additional response parameter question_id needed? 1) the client just send the question_id as part of the GET request to the server and 2) it is included in user_statement_token. I would suggest to directly return the statement.

-          Section 7.3

o   "The OP sends the User Questioning Response to the Client using HTTP POST." I would call this a request.

o   Re question_id - same comment as above for Section 7.2.3

o   It seems SIBA and your draft use different philosophies of how to cope with error results. UQ uses a status response parameter to distinguish success from error and gives additional data whereas SIBA just either sends error data or the requested data. I would like to align on that topic as well.

-          Section 10

o   I think 10.1. belongs to section 7.1.. It describes considerations the OP should take into account while processing the questioning transaction.

o   Same for 10.2., potentially better placed in 7.2.3 and referred from 7.3.1

o   I think 10.3 and 10.4 essentially talk about the same topic.

o   You don't see further attack vector against UQ?

-          Section 12

o   Please move this up as this is highly relevant for all implementers. For example, the account porting explains this in its 2nd section.

Best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von nicolas.aillery at orange.com
Gesendet: Mittwoch, 2. November 2016 17:35
An: openid-specs-mobile-profile at lists.openid.net
Betreff: [Openid-specs-mobile-profile] [User Questioning API] Fourth draft

Hello all,

   Here is a fourth update of our draft for the User Questioning API,

Regards,

Nicolas


_________________________________________________________________________________________________________________________



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/20161113/eb629910/attachment-0001.html>