+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) > >
-- --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
