[Openid-specs-mobile-profile] CIBA Abstract and Introduction

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Thu Dec 8 12:55:29 UTC 2016

Sorry, wrong subject line in last email:

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Nennker, Axel
Sent: Thursday, December 08, 2016 12:46 PM
To: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] UQ comments

Dear all,

I added some text to the CIBA abstract and introduction hopefully making it clearer what CIBA is about.


Main points of CIBA:

-          No consumption device under the user's control
binding_message might be communicated through RP's agent

-          Server to server no redirect

-          Does not change semantic of OpenID Connect Authentication (parameters nor parameter values)

-          Removes OpenID Connect Authn parameters that make no sense in a server to server no redirect scenario

-          Add a few parameters for asynchronous result delivery.

-          Does not change content nor format of tokens

-          Does not introduce new scopes in Authn request


From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of nicolas.aillery at orange.com
Sent: Wednesday, December 07, 2016 12:00 PM
To: Manger, James
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] UQ comments

Hello James,

   Here are my comments.


PS: draft 10 has been pusblished

De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Manger, James
Envoyé : mercredi 7 décembre 2016 07:47
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Objet : [Openid-specs-mobile-profile] UQ comments

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


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.

[NAY] UQ and CIBA are both server to server API, but I don't think they offer the same functions and address the same use cases. Merging them on the basis that they are server to server API would be a shortcut.

UQ API aims at questioning a user and returning an OP asserted answer to the Client. The Client can then enforce its policy. We gave a list of business use cases where this feature is useful.

About CIBA, nor CIBA features neither addressed use cases are clear for us. In our understanding, CIBA is interesting when there is no UA and the OP has to deliver an Access Token (i.e. an access right to OP's APIs). The business use cases for this are not clear.

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.

[NAY] Agreed. 'displayed_statements' added in the User Statement Token in draft 10.

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."

[NAY] Agreed. Modified in draft 10.

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

[NAY] Agreed. Modified in draft 10.

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

[NAY] Agreed. Modified in draft 10.

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

[NAY] Agreed. Modified in draft 10.
        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.

[NAY] we reused the OIDC Core structure. I see no elegant place to put this chapter.

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.

[NAY] Yes, question_id is like a request_id. I'm not sure it's worth modifying the draft.

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

[NAY] Agreed. Modified in draft 10.

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"?

[NAY] The UQ API delivers User Statement Tokens and these tokens have a specific structure (question_id, displayed_question, displayed_statements, statement). Except if this 'typ' is added to all OIF specifications, I don't see benefits in the UQ API case.

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

[NAY] We could amr and acr, but as there are amr/acr in the User Questioning Request and amr/acr in the User Statement Token, and as those amr/acr doesn't have semantic

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

[NAY] 'iat' stands for the JWT creation date. In this API, the 'statement_date' is more important. 'iat' could be added, but I don't see relevant use case for it.

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

[NAY] Agreed. Modified in draft 10.

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.

[NAY] We added the 'wished_amr' because it's a need we already have on our OIDC implementation. Today, we have to deal with specific client_id or other tricks. Having an optional 'wished_amr' would have helped a lot. It's the reason why we want it in the UQ API.

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..."

[NAY] Agreed. Modified in draft 10.

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.

[NAY] Agreed. Before modifying the draft, I prefer to wait for a common OIF approach on polling.

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.

[NAY] Agreed. It's from the early drafts when we used to return content. Before modifying the draft, I prefer to wait for a common OIF approach on polling.

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

[NAY] In the current draft, the HTTP response (from the RP) is ignored. For me, this means not redirect, no retry on error, ... On this, I prefer to wait for a common OIF approach on client notification.

James Manger


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/20161208/542f3ac9/attachment-0001.html>

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