Well, F2F at IIW is a good place to cook the things, but we have to
ready the materials to be cooked by then.
Having some kind of viable proposal on the table at the time of F2F will
be much more productive than not.
Protocol flow-wise, the current proposal on the wiki is fairly boiled down.
We are right now trying to implement it on JanRain library to fine tune
the parameter choices so that implementers will have less to do. That
kind of things cannot be done on-the-fly at the F2F.
Another thing that cannot be done at the F2F is to test the scalability
impact.
I am hoping to get feedback/estimation from Yahoo, Google etc. on this
so that we can discuss it in depth at the F2F.
I will also get feedback from Japanese mega-providers.
I will create another thread on the XRD based Discovery as well.
These are the two big item that I want to discuss at IIW.
=nat
Breno de Medeiros wrote:
+1 for postponing this discussion until then
On Mon, Aug 24, 2009 at 6:45 PM, John Bradley<john.brad...@wingaa.com> wrote:
I think we have a number of potential ways to skin the proverbial cat.
We can certainly talk this to death.
At some point someone is going to have to do some standards work and pull
this together.
IIW is probably the next time we are getting together.
Do we want to try and seriously start something before that?
John B.
On 24-Aug-09, at 9:15 PM, Breno de Medeiros wrote:
OAuth does not authenticate the OP (Service Provider in this case) and
therefore you would have to know a priori arbitrary bindings of OPs to
artifact endpoints. Of course, this could be addressed through
discovery and if the OP supports SSL then the difference becomes
negligible.
Also, since this does not require necessarily an authenticated RP,
then you could ask what is OAuth buying you anyway. So you only need
the XRD part of the XRD+OAuth combo. Hey wait, you still need some
additional semantics about making user authorization requests and
about attributes, and at that point, using an OpenID-based artifact
(which is a variant of stateless mode) sounds like a much more
lightweight way to go about it than defining the same additional
semantics for OAuth + throwing away requester signatures and keys,
etc., etc.
On Mon, Aug 24, 2009 at 6:05 PM, John Bradley<john.brad...@wingaa.com>
wrote:
The thing that doesn't do for Nat is reduce the size of the request.
I suppose that there could be a standard oAuth attribute service.
The largest problem is having the OP know what to have the user
permission.
One option is to have the OP retrieve a policy document directly from the
RP
so that the user can give consent to what the RP is going to get a oAuth
token for.
Following this path at some point you would ask what the openID portion
of
openID+oAuth is doing for you?
So if you add discovery XRD/S to oAuth + a way to deliver a RP policy,
do
you have a viable alternative to a openID artifact binding.
Perhaps a heretical question, but one we should probably explore before
reinventing things.
John B.
On 24-Aug-09, at 8:45 PM, Allen Tom wrote:
Hi Nat,
Have you considered using the OpenID OAuth Hybrid Extension instead of
defining a new Artifact binding?
http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html
The openid.oauth.request_token response parameter in Section 10 is
essentially the same thing as an Artifact. Google already supports the
Hybrid extension, and Yahoo will be launching support for it in the very
near future, so perhaps we could use use Hybrid to support large
responses?
Allen
Nat Sakimura wrote:
Updated http://wiki.openid.net/OpenIDwithArtifactBinding
1. Added description in overview.
2. Added signature in artifact related requests.
3. Separated the Artifact Authentication Request from the
Authentication Request and created section 9.1.1 for more readability.
4. Removed 9.4 and moved the text to 9.
5. Other miscellaneous changes.
For complete list, see the wiki history.
Feature-wise, it is almost complete for the Artifact binding, IMHO.
Need feedback from large providers.
=nat
_______________________________________________
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
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
