Just a personal memo on OASIS process as one of the TC chair, but OIDF should develop this kind of chart as well, I think.

Due to an ever-increasing workload I must ask that each request be sent in a separate e-mail message unless related to a single, multi-part specification. As a reminder, a chart showing exactly what needs to be included with each request can be seen here:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html

To ensure the quickest possible handling of your request, make sure to
1. review the checklist: http://docs.oasis-open.org/templates/QAChecklistV3.html
2. Include the requisite information in the request:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html
3. do not include more than 1 document in any single request.

Thank you for understanding.

Regards,

Mary

The wrap_scope, especially when it is determined dynamically using standard vocabulary such as something similar to OpenID AX, can become quite big. Under such circumstances, we may hit the browser/server constraint on URL and HTTP header. This is more acute in the mobile scenario.

Lucky thing is that it is trivial to create an Mobile friendly profile / binding of OAuth Wrap, since it is almost done. It suffices just to introduce a request artifact.

Here is the flow:

(fig.1) Wrap Mobile Web Profile

Of course, details need to be nailed down, but the basic flow should be it.

People may criticize that it introduce state in the AuthzServer. It may, but it is not necessarily so. Since the AuthzServer knows what it can serve, it has constrained set of scope and may well be able to encode it into an Artifact, so that it does not need to keep the state.

–
(Feb 12) Fixed typo in the figure.

Like there can be OpenID GET/POST and Artifact Binding for CX, there can be WRAP binding as well. It is fairly trivial, arguably more trivial than to define OpenID bindings.

1. Send CX proposal as an additional parameter on the Verification Code Request. Use wrap_client_id as the proposer’s identifier.
2. On the PoP verification page, display the terms and conditions included in the proposal.
3. Create the Verification code from the signature of the proposal and some nonce and random.
4. Web App Client sends the proposal again as an additional parameter on Access Token Request.
5. Sign the proposal to create the contract, serialize it with Base64 without line end, and return it as the access token on Access Token Response.

That’s all.

In the current Artifact Binding manuscript, the artifact is being defined as a string shorter than 400 bytes. Some people asked why 400 and not 512, which is the limit of some mobile browsers?

The answer is that we use 80 bytes in the fixed string:

?openid.ns=http://specs.openid.net/auth/2.0&openid.mode=art_res&openid.artifact=

Suppose we use 400 bytes in Artifact. Then, the total is 480 bytes.
That leaves 32 bytes to the non-query portion of the URL.