[Openid-specs-mobile-profile] UQ comments

[Manger, James]

Comments on OpenID Connect User Questioning API <draft-user-questioning-api-09> (UQ):

Overall

1.       Combine UQ and CIBA -
Their use-cases (confirming answers vs confirming a login) are on the same continuum and there is a lot of overlap in functionality. They differ in some design choices (new endpoint vs reuse token endpoint; access_token vs client cred; ...), but these are exactly the choices where we should standardize on one choice. Where we are really unable to reach consensus on one choice, put in both options. At least each choice becomes more apparent.

2.       [2] The signed statement only covers the chosen answer, not the other choices. This could be misleading? For instance, an answer to example #6 in §1.5 ("Which is your favorite brand?") could be "brand_B", but that could mean you favour B over A & C; or you favour B over D (but would have favoured A if it was a choice). Include all the choices in the signed statement, along with an indication of the chosen one.

Other comments

3.       [Abstract] Mention that an OP is involved.
"This specification defines an API offered by an OpenID Provider (OP) that can be used by an application to send a question to a user of the OP. The user does not need to be interacting with the application when the question is asked. The user's answer is returned asynchronously, digitally-signed by the OP."

4.        [1.3] "its digitally signed response" implies the user does the signing, but actually the OP does.

5.       [1.4.1, 1.4.2] Move the common sentence about (2a) to 1.3 since it is common to pull & push flows.

6.       [1] Mention that the question and any multiple-choice answers are each a short textual message; perhaps including 1 example.

7.       [2] The answer (user statement token) is described before the question (4.1.1 User Questioning Request), which isn't the most intuitive arrangement.

8.       [2] I assume "question_id" identifies a specific instance of asking a user a question. It isn't an id just for a question itself, which could be posed to many users many times. Perhaps "request_id" would be a better label.

9.       [2] "Do you allow ...?" is not a great sample question.

10.   [2] There is no single field that ensures the semantics of the signed statement are unambiguous. How about setting the "typ" parameter to "openid-connect-user-question"?

11.   [2] Can't we use "amr" & "acr", instead of "used_amr" & "used_acr"?

12.   [2] Why not "iat" (issued at), instead of defining a new "statement_date"?

13.   [4.1.1] Uses a mix of SHALL and MUST; better to consistently use one.

14.   [4.1.1] An OP returning the auth method used (amr) is okay, but clients shouldn't be able to ask for specific methods. It's too fragile; too likely to break when a new method is introduced. Clients asking for an acr is at a better level.

15.   [4.1.1] Can't really say "MUST be displayed with no modification" then in the very next sentence say "if modifications occur...". Rephrase as "SHOULD NOT be modified..., the only exception being..."

16.   [4.2.1] I doubt an HTTP header (Client_timeout ) is a good idea to indicate client support for long polling, unless there is a standard HTTP header for this. How about another query string parameter? We should add some suggested wait time (and servers should accept anything larger). I don't know much about long polling in practice, but it sounds like 20s is about the max to try.

17.   [4.2.3] 304 Not Modified isn't the right polling status when the statement is still pending. Can't return 304 if no previous content has been sent for a URI. 202 "Accepted" might be a better choice.

18.   [4.3.4] Can the RP's notification endpoint return a redirect that the OP will follow? Hopefully.

--
James Manger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161207/3ee10b85/attachment.html>