[Openid-specs-mobile-profile] Regarding 4.3.1 Successful Response with User Questioning Response

Celestin Bitjonck celestin at allfocusit.com
Thu Nov 17 16:58:43 UTC 2016


I tend to agree with Axel. If the status=="OK", there should not be a need
for question_id.

 

Celestin 

 

 

From: Openid-specs-mobile-profile
[mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of
Axel.Nennker at telekom.de
Sent: Thursday, November 17, 2016 9:45 AM
To: nicolas.aillery at orange.com; charles.marais at orange.com
Cc: openid-specs-mobile-profile at lists.openid.net;
Torsten.Lodderstedt at telekom.de
Subject: [Openid-specs-mobile-profile] Regarding 4.3.1 Successful Response
with User Questioning Response

 

Why send question_id when it is a MANDATORY part of the signed
user_statement_token already?

The spec states that the Client SHOULD check that both match but does not
say what to do if they do not match.

I suggest to change 4.3.1 to: if status=="OK" then the response MUST NOT
have a question_id member field.

If status=="error" then question_id is MANDATORY.

 

Axel

 

I am not sure about using "status" at all. Why not just have the response
have a user_statement_token OR an error field?

Probably a question of personal preferences.

  

 

 

From: Openid-specs-mobile-profile
[mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of
Nennker, Axel
Sent: Thursday, November 17, 2016 1:25 PM
To: nicolas.aillery at orange.com; charles.marais at orange.com
Cc: openid-specs-mobile-profile at lists.openid.net; Lodderstedt, Torsten
Subject: [Openid-specs-mobile-profile] User Questioning RE: minutes of
MODRNA WG Call Nov 16th 2016

 

Hi Nicolas, hi Charles,

 

I reviewed the UQ draft and here are my first remarks:

 

-                          Please consider whether the word "FORBIDDEN" can
be replaced by "MUST NOT"
e.g. in 4.1.1 I suggest to reverse the order and rephrase to avoid
FORBIDDEN:
"MANDATORY if the Access Token is not tied with an End-User. MUST NOT be
present if the Access Token is tied with an End-User,"

 

Regarding 4.1.1 User Questioning Request

-                          "AUTHORIZATION" the paragraph seems to exclude
the possibility to use client_id/client_secret and BASIC auth, right? Or
does use of client_id/client_secret constitute the case "not tied to the
user" while an access token constitutes the case "tied to the user"?

-                          user_id "tied to the user" should be explained. I
suggest adding text to the paragraph about "AUTHORIZATION" and the access
token.

-                          user_id versus sub
Why not use sub always instead of user_id? "sub" has the advantage that it
is not widely known because it was assigned by the OP to the user for this
Client. "sub" is never reassigned while a user_id might not be eternally
assigned to the user. Yes, User_id_type can be sub but sub is harder to
misuse by a rogue Client.

-                          4.1.2.2 says "user_id as a reachability means":
Should the OP be free to decide how to contact the user on which device? Or
does the Client decide on that by requesting a certain channel/device to be
used?

-                          I suggest to add "sub" as MANDATORY to the UQ
request.

-                          "wished_acr" Why not use "acr_values" from
OpenID.Core?

-                          "wished_amr" like acr_values?: amr_values?

-                          "wished_*" is the order of the values important?
There is no text regarding the order.

-                           

Regarding 4.1.2.2 Processing user_id

-                          I would not conflate user_id as sub and user_id
as reachability means!

-           Wondering about the wording here:
"If the user_id is present in both the User Questioning Request and the
Access Token, an error is raised."
If the access token is "SlAV32hkKG" does this cover the "present in"
wording?
How about: "If the user_id is present but the Access Token is bound to a
user then the user_id and the sub associated with the Access Token MUST be
identical". (Not replacing user_id by sub in this for now. I think the
parameter "user_id" should be replaced by "sub" and a reachability
parameter)

Regarding 4.1.3 Successful Response

-                          I am not sure whether transporting the polling
URL in the Location header.

-                          I am not sure whether the polling location should
be dynamic.
Being dynamic has advantages because it can be dynamic based on client
and/or question and/or server load etc.

-                          Being dynamic has the disadvantage that the
Client has to decide at polling time whether some policy might forbid it to
talk to the polling endpoint.

The example does not contain a JSON structure! Should this read like this:
HTTP/1.1 200 OK

{  "Location":
"https://server.example.com/questions_polling/984dcc7d3d4d4b0f9f8022e344f9",

   "Question_id": "984dcc7d3d4d4b0f9f8022e344f9"
}

 

Regarding 4.1.4 Error Response:

Why is this different to OAuth2 Section 5.2 Error Response?

https://tools.ietf.org/html/rfc6749#page-45

 

Regarding 4.3.2 Error Response

Like 4.1.4 make this look more like OAuth2 Section 5.2 Error Response?

 

Regarding 6.1 Implementation of questioning methods

-                          Change headline to headline style (Capitalized
Words)

-                          Add supported AMR and ACR etc to discovery.
"To prevent these errors, it can inform the Clients of its limitation and
limit the possible questions or statements."

 

 

Have to go now - So stopped reviewing for now before section 7 Security
Considerations.

 

Cheers

Axel

 

 

 

 

From: Openid-specs-mobile-profile
[mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of
philippe.clement at orange.com

Sent: Wednesday, November 16, 2016 6:07 PM

To: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net

Subject: [Openid-specs-mobile-profile] minutes of MODRNA WG Call Nov 16th
2016

 

Please find below the preliminary notes of the call. 

Should you detect any error or misunderstanding, please let me know.

 

Participants : John, Axel, Bjorn, Charles, Torsten, Joerg

 

Agenda :

 

. Review UQ specs

. Review SIBA specs

. Next workshop

 

Discussion :

User Questionning

A new draft has been released by Orange, following questions/remarks from
Torsten

Axel and Bjorn volunteer to review the UQ draft specs. 

Torsten to send a reminder to the list for reviewing, before entering the
implementers draft process.

A proposal is made for OIF to present a status update of UQ work at the next
PET GSMA meeting (end of November). Orange will help to draft this
presentation. PET chairman to be contacted for insertion into the agenda.  

 

SIBA

Questions about the context parameter that shows up in the specs.
Discussions in Paris had only stated a use for the binding message to
interlock devices. Recommendation from the call is to remove this parameter.


Charles volunteers to post comments on SIBA specs, other comments are
awaited from the list.

Mentionning the Use Cases in SIBA specs is requested to understand some
choices in the specs, and will avoid any duplication with User Questionning.

 

Idea of merging some parts of SIBA and UQ are set on the table, but draft
specs should be more mature.

 

Next workshop

For information, John should be in London January 18 and 19th, to take into
consideration.

 

AOB: push style

Discussion occurs on OAuth list regarding push style for the device flow.

Some arguments are presented to balance push vs pull approach, for UQ.

. Complexity for the RP to implement 2 solutions

. Resource optimization from an OP side

. Number of requests per second

. Delay for the user to answer the question (seconds, minutes ?)

Discussion to be continued on the list through the specs

 

Best regards,

Philippe

 

____________________________________________________________________________
_____________________________________________

 

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/20161117/bb91486c/attachment-0001.html>


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