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

nicolas.aillery at orange.com nicolas.aillery at orange.com
Tue Nov 15 12:09:58 UTC 2016


Hello Torsten,

  Thanks for your review.
   I just updated to draft to v6.


   Please, find my comments in the text.
   (no comment means that the spec has been updated)

   Tomorrow, I won't be able to attend the meeting. Charles will attend.

Regards,

Nicolas

De : Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de]
Envoyé : dimanche 13 novembre 2016 12:47
À : AILLERY Nicolas IMT/OLPS
Cc : openid-specs-mobile-profile at lists.openid.net
Objet : AW: [User Questioning API] Fourth draft

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?
[NAY]  I don't like the idea to format the polling URL in the specification. If an OP wants to use the question_id as a path or in a query, it should be its choice. If it prefers not to put the question_id in the polling URL, it's pure implementation choice.
Using a static URL add something more in the registration process, but I don't see the benefits.
Ok for a decision on this by the group. But I would like people to read the spec before (I still hope more reviewers).


-          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.
[NAY]  Having the question_id simplifies the security checking (do I know this client_notification_token? do I know this question_id?)
The question_id is mandatory for Error Response.
It's OK to align on something that makes sense.


-          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.
[NAY]  10.3 is just about Non-repudiation. 10.4 is about the encryption and signature mechanisms.

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.

_________________________________________________________________________________________________________________________

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/20161115/ac089289/attachment-0001.html>


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