[Openid-specs-mobile-profile] binding_message and context

Fri Dec 2 09:28:38 UTC 2016

Hi all,

My thoughts on context and binding_message:

-          CIBA should stay away from user questioning (UQ) territory
CIBA and UQ have different purposes and those should not be mixed by e.g. abusing context for user questions.
So when UQ's user_statement and id_token convey more or less the same semantic then we should only have one protocol but this is not the case:
CIBA is about RP initiated getting of user authentication and tokens
UQ is about asking questions and getting answers from users

-          Binding_message is a good security practice and SPs should use it even if the "consumption_device" is e.g. a bank clerk.

-          I think that binding_message should be generated by the OP because the OP knows best what channel should be used to contact the authentication device and its UI capabilities.

-          Messages provided by the RP to the user bear risk to be misleading or a plain phishing attack...

-          In the current redirect OpenID Connect dance the OP is presenting the consent screen to the user to ask which attributes/claims are part of the id_token and who the RP is and what the access token can be used for.
I think that we should not change the role of the OP in CIBA.
The OP knows best what channel and UI capabilities are available.
If the RP needs arbitrary text conveyed to the AD then the RP should use UQ

-          If we allow binding_message and context to be specified by the RP then we have to deal with the error cases e.g.:

o   Binding_message too long

o   Binding_message contains characters that are not displayable on the AD

o   Context to long

o   Context contains characters that are not displayable on the AD

o   Binding_message + Context + Consent-text (e.g. RP wants to edit your timeline) are too long to be displayed

This complexity can be avoided when the OP generates the messages.

-          In OpenID Connect the OP shows the consent pages - why should we change that in CIBA? There is no new liability for the OP.

Kind regards
Axel

The above is more or less the same as what I wrote in a GSMA context email - There liability was raised.

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Petteri Stenius
Sent: Thursday, December 01, 2016 4:59 PM
To: openid-specs-mobile-profile at lists.openid.net
Subject: [Openid-specs-mobile-profile] Async authentication with polling and callback

Hello everybody

At the Paris meeting in September there was some discussion about polling and callback mechanisms related to asynchronous functions.

These mechanisms exist in both UQ and SIBA draft specifications. Polling is also defined in OAuth Device Flow draft.

This proposal is an attempt to generalize async polling and callback mechanisms:

*         Define polling on the http level, not an application level function

*         Callback is only a simple notification request, a client initiated request is required to fetch the actual content

The two proposals work together, and make for example switching between polling and callback mechanisms very easy.

Thanks,
Petteri

Polling defined on the http level

Define mechanism with HTTP 303 redirect and Retry-After response header.

303 redirect is used to define polling as sequence of http redirects the client follows until async operation completes and response appears.
The client MUST wait time indicated by Retry-After header before following a redirect. Failing to do so would result in 503 Service Unavailable error (with Retry-After header).
Semantics is comparable to "Wait a moment, the response will soon appear at this location"

The server is allowed to implement "long polling" by holding a response up to 30 seconds (see https://tools.ietf.org/html/rfc6202#section-5.5)

Example of polling sequence:

1.       Client begins async operation

POST /begin-async-operation HTTP/1.1

2.       Server response with 303 status indicates client must begin polling for response. Server encodes state into querystring of redirect uri

HTTP/1.1 303 See Other
Location: /async-response?opaque-server-state-1
Retry-After: 10

3.       Client waits at least 10 seconds before following the redirect

GET /async-response?opaque-server-state-1 HTTP/1.1

4.       Server response with new uri where querystring has changed

HTTP/1.1 303 See Other
Location: /async-response?opaque-server-state-2
Retry-After: 10

5.       Client again waits before following the redirect

GET /async-response?opaque-server-state-2 HTTP/1.1

6.       Server response with content when async operation has completed

HTTP/1.1 200 OK

"completed"

Callback is a simple notification request

My proposal for callback mechanism is a simple notification request.
Server encodes any state it needs into querystring of the notification request.
For the client the querysring is opaque and the client must pass it as-is when fetching the actual content from the server.
Using a simple notification request removes the requirement for client to authenticate the callback request from server.

Example of callback sequence:

1.       Client begins async operation

POST /begin-async-operation HTTP/1.1

2.       Server response with 202 status indicates client needs to wait for callback

HTTP/1.1 202 Accepted

3.       When async operation completes server sends a notification request to client. Server encodes state into querystring of notification uri

GET /callback?opaque-server-state-3 HTTP/1.1

4.       Client response is not processed by server

HTTP/1.1 204 No Content

5.       Client creates request uri and fetches content from server

GET /async-response?opaque-server-state-3 HTTP/1.1

6.       Server response with content

HTTP/1.1 200 OK

"completed"

Related discussion

[Openid-specs-mobile-profile] Async authentication
http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20161010/000615.html

[OAUTH-WG] polling in the device flow
https://www.ietf.org/mail-archive/web/oauth/current/msg02939.html

[OAUTH-WG] Device Flow: Alternative to Polling
https://www.ietf.org/mail-archive/web/oauth/current/msg16723.html

References

OAuth 2.0 Device Flow
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03

HTTP/1.1 Semantics and Content
https://tools.ietf.org/html/rfc7231

Retry-After
https://tools.ietf.org/html/rfc7231#section-7.1.3

Best Practices for the Use of Long Polling
https://tools.ietf.org/html/rfc6202

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