Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

Hi

I was wondering if we could define an Artifact Binding/Mobile Profile for Wrap. 

The way I would do is pretty simple because Wrap Web App Profile is an Artifact Binding to some extent. 

Just send Verification Code Request directly from WebAppClient to AuthzServer 

and get an Artifact back and bring that to AuthzServer through UA. 

After PoP, another artifact is created at AuthzServer and 

it is brough back to the WebAppClient through UA redirect. 

Then, the verification Code Response can be obtained from AuthzServer  directly using the artifact. 

The rest is the same. 

I created an blog entry with pretty diagram at 

http://www.sakimura.org/en/modules/wordpress/oauth-wrap-mobile-web-app-profile/

It may be easier to see the page instead of the above description. 

(Instead of using response artifact, Verification Code Response can be sent directly, 

 but then we would be introducing AuthzServer -> WebAppClient communication, which would have 

 some implication on firewall configuration.) 

For those of you who say that "Artifact is Complex", see the original Web App Profile here: 

http://www.sakimura.org/en/modules/wordpress/oauth-wrap-web-app-profile-summary/

It is almost identical. 

Added value is that is is more "mobile" friendly, and is actually more secure if the 

Request Artifact and Response Artifact (wrap_verification_code) is generated cryptographically

strongly. 

What would you think? 

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

[Allen Tom]

+ [specs@openid]

Nat – this is exactly what I had in mind. In many ways Oauth and Oauth-WRAP are  similar to artifact binding – the user approves a token, which is then passed back to the RP via a browser redirect. The token is then used by the RP to make web service calls on the OP to access a Protected Resource.

The token is kind of like an artifact, and the Protected Resource can be an OpenID assertion.

Would we be able to combine the OpenID Artifact Binding Extension with OAuth WRAP? If so, that would be great.

Allen

[Nat Sakimura]

The flow is almost exactly the same. There are few differences due to the way specs in each communities are supposed to be written. 

1) OpenID mandates that the prefixes are openid. and Wrap does so with wrap_

2) Wrap presumes TLS while OpenID currently cannot. 

2a) Thus, OpenID needs signature, and so it requires association. 

3) OpenID has built in identifier and discovery system while Wrap does not. 

etc. Otherwise, these two are almost identical. 

The hardest one to resolve actually is the name space qualifier/prefix and parameter names, obviously. 

OpenID has a lot of installation, and it is not easy to convert them overnight. 

As the OpenID Artifact Binding tries to be as compatible as it can be with GET/POST Binding (aka OpenID 2.0), it is not so easy to achieve the full convergence with Wrap in a very short term, unless wrap is prepared to assume openid variable names. 

For a longer term, there is no reason that they cannot be unified. 

OpenID and Wrap community should come closer and work on how we can bring them together. 

For the artifact binding on both side, we should try to make them compatible apart from the variable names. Then, in the future, when both sides revs up, it should be trivial to unite. 

=nat

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Nat Sakimura]

If you look at my manuscript of the Artifact Binding (http://www.sakimura.org/specs/ab/1.0 ) , it is clear that the Artifact is created and consumed by OP/AuthzServer and is opaque to RP/WebAppClient. It has no restriction other than that it should be below 400 bytes. (NB: It is much bigger than SAML's 30bytes limit). 

Or, if you are talking about the Access Token in fig. 1 of http://www.sakimura.org/en/modules/wordpress/oauth-wrap-mobile-web-app-profile/ , then, it is also completely opaque. It does not even have the size limit. Only the condition is that AuthzServer and Resource has the common understanding of what it is. 

=nat

On Thu, Feb 11, 2010 at 7:56 AM, John Bradley <john.b...@wingaa.com> wrote:

In principal it would work.  The only downside is that the artifact/token might be smaller if it were a simple SHA256 XORd with the association secret or something like that. 

I like the concept in principal if it doesn't compromise the ability to have a small response via GET.

I had questions around the token format returned by the protected resource.(artifact resolution)

John B.

_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

[Allen Tom]

Hi Nat -

As an optimization, can we combine the association request with the artifact request? In fact, why can’t the association handle be the artifact?

For example, when the RP requests association, it can pass along all the request parameters that it normally would pass via the browser in the authentication request. The OP can then return the association handle/artifact along with the shared secret.

The RP then redirects the user’s browser to the OP with the association handle. After the user authenticates, the OP redirects the browser back to the RP with the association handle.

The RP then makes a direct server call back to the OP with the handle (and probably also the shared secret) to fetch the assertion.

I think this scheme will save a couple round trips.

Allen

On 2/11/10 9:55 PM, "Nat Sakimura" <saki...@gmail.com> wrote:

[Nat Sakimura]

Hi Allen, 

That can be done, but there are a few things to be considered as well. 

1) Association is a rather expensive operation. We might not want to do it with 

    every authentication request. 

2) Breno wanted to have something like 400 bytes or so to achieve statelessness in  255bytes restriction may be too short for him. 

3) Breno (and you I think) wanted to have the request artifact and response artifact different. 

3) This would probably mean that we need to touch the core library in many case and arguably has larger impact - which means that we may end up with more adoption friction. (BTW, we actually wrote test code in Java, Python, PHP, and Ruby to see if the draft can be implemented without touching the core library.) 

4) In the longer term, I am suspecting that association might be disappearing (like it did in Wrap) so depending on it might not be a good idea.  

In fact, initially, I was thinking the same with you half a year ago, but after a while, I have abandoned the idea. Assuming that association happens once in every hundreds of authentication request, it just buys me 0.01 round trip per authentication request or less. It is going to be even less for a large provider. I could probably trade that round trip with the benefit gained from the above reasons. That's why I did not piggy back on the association. 

=nat

[Allen Tom]

HI Nat -

Why is association expensive? It should be no worse than issuing an artifact. I guess it depends on the underlying implementation.

The point of the association is to eliminate the extra round trip (aka dumb mode) - however artifact mode by definition requires an extra round trip. I have not thought about this too deeply, however I don’t think the association step adds anything when artifact binding is used.

What is the point of having different request and response artifacts? I don’t think that’s necessary.

At least in Yahoo’s case, we can probably get by with artifacts/associations that are well under 255 bytes.  Our OAuth Request Tokens are only 8 bytes, and that’s large enough.

Allen

[Nat Sakimura]

On Tue, Feb 16, 2010 at 1:34 PM, Allen Tom <at...@yahoo-inc.com> wrote:

HI Nat -

Why is association expensive? It should be no worse than issuing an artifact. I guess it depends on the underlying implementation.

AES or SHA1 is computationally much cheaper than DH, I think. 

If the main reason for the combining association and artifact request is to save round-trips, it does not save so much. 

Suppose Association is done only once in a day, and there are 1 million authentication in a day, you are saving only 

0.0000001 round trip per authentication, or equivalently, one round trip per day per OP-RP pair. 

In return, you have sacrificed

1) Computational resource (both CPU and storage since now you have to store the association for every user instead of just OP-RP pair)

2) Ability to sign the artifact request

3) You cannot use different artifact in the request and response, making it rather difficult to implement stateless Artifact mode. 

Breno - please elaborate on 3). Briefly stating, if request and response artifacts are allowed to be different, the OP can encode all the information into the artifact in a proprietary fashion so that OP can achieve the RESTful artifact mode. 

See: http://lists.openid.net/pipermail/openid-specs/2009-August/005939.html

and http://iiw.idcommons.net/OpenID_Artifact_Binding

=nat 

 

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Breno]

Maybe I'm missing something, but why is it beneficial to re-use the association request?

The current OpenID spec does not make the association request extensible, so whether you declare an artifact mode or modify the association request you have to modify the core spec.

Breno de Medeiros

[John Bradley]

I suspect the advantage to extending the association is more political,  that way you can call it an extension.

I think practically it is better to keep the exchange of long term secrets (Association) separate from the artifact resolution process.

If we want to do per request shared secrets say SHA256 vs re-using the long term one I don't have a big problem with that.

I don't yet see a super compelling reason for it though.

John B.

[John Bradley]

Allen,

A shared secret is still required, for artifact. 

In the artifact case it is being used to authenticate the RP to the OP fro artifact resolution.

I agree that the IdP signature over the token is not all that useful if you have just directly retrieved the token from the OP.

I suspect that association is only expensive if you are doing DH.

I think we should be realistic and require OP to use SSL to avoid DH associations.

When the RP asks for an artifact handle in the direct request you could return the handle and a handle secret.

Effectively a per request association.

I suspect that Nat didn't propose that to keep the amount of changes to the core library down.

Getting rid of the association is only saving about one request /4h per RP.

I suspect the idea in allowing a different response is so that an OP could encode the actual response in the artifact.  

Sort of a compressed token.    It adds complexity to the RP.

I personally think having a very small artifact, that stays the same in the request and response is better.

There could be an optional value/token that gets returned in the indirect response and passed back to the OP as part of the direct query.   That might be a better compromise between the approaches.

This is probably something that should be discussed in the WG.

John B.

[John Bradley]

Sure a association request is extensible if you change the core spec:)

I prefer to come up with the best design then work around the politics.

I understand Nat has been trying to make progress on this as part of CX and then on it's own.

I am going to be at RSA if Nat is going perhaps we can get together there before the openID summit the following month.

John B.
On 2010-02-16, at 11:53 AM, Breno de Medeiros wrote:

> On Tue, Feb 16, 2010 at 04:22, John Bradley <ve7...@ve7jtb.com> wrote:
>> I suspect the advantage to extending the association is more political,
>> that way you can call it an extension.
>

> I could, but I'd be fabricating. The association request is not extensible.

>
>> I think practically it is better to keep the exchange of long term secrets
>> (Association) separate from the artifact resolution process.
>

> I agree.

>
>> If we want to do per request shared secrets say SHA256 vs re-using the long
>> term one I don't have a big problem with that.
>> I don't yet see a super compelling reason for it though.
>> John B.
>

> Ditto.