Re: [mmox] OGP scalability concerns

[Christian Scholz <[e-mail]>]

Hi!

Meadhbh Hamrick (Infinity) schrieb:
> yup. for what it's worth, i had several good chats with mark atwood at 
> the ietf meeting. he's coming down to the bay area for the mysql 
> conference, i hope to buy him a beer some evening and run a few 
> proposals past him wrt OAuth and it's use in OGP.

I would actually like to learn more about those conversations you had at 
the meeting ;-)
And I am still looking forward to hear more about the ProtectServe stuff 
they are working on.

> and. ack. i should probably have mentioned this earlier. i got a lot of 
> good feedback about the drafts we published, and one of the things 
> that's going into the next rev of the auth draft is how to deal with 
> transport authentication ( like when your transport manages 
> authentication for you like client side certs and HTTP digest 
> (*shudder*) ). eventually OpenID should go into a similar section, but 
> we feel there are still a few open issues with it's use. declaring the 
> solution to being "we just use XRI" and declaring victory seems a little 
> hasty, but it seems like there's enough interest to warrant it's 
> inclusion in any future charter / IDs / etc.
> 
> i haven't heard anyone say they have serious problems with OpenID in 
> general. i mean... if someone was implying that OpenID kills puppies, i 
> missed it. that being said, XRI / XRDS and OpenID are not in universal 
> use, so it's unlikely a statement like "OGP will only ever use OpenID" 
> will ever pass the humm test. but the statement "OpenID and XRDS should 
> forever be banished from OGP" will also never pass the humm test.

I personally did not want to imply that OpenID should be the only thing 
to support. We always talked about some pluggable mechanism for 
authentication and I still think that's the way to go. As for a service 
catalogue it could simply list several authentication methods and the 
other side can select the best suited one.

> which is to say... if anyone's willing to do the work to figure out how 
> to wedge OpenID into OGP, i'm all for it. to be clear, in this context, 
> the word "work" means:
> 
> 1. you work with other list members requirements.
> 2. you produce a document describing how OpenID or XRDS can be used in 
> conjunction with the existing spec (though the existing specs are cast 
> in jello, not in stone, so there's some room to modify them if we 
> absolutely have to.)
> 3. producing code to demonstrate it's use.. *cough*PyOGP*cough*

I am certainly willing to work on use cases, requirements and discussing 
a solution but my personal priority would be on the general social 
networking case, not OGP (which might mean of course that this work 
might also be done outside this group if there is no interest in that). 
I am also not sure how to mix it with OGP. OAuth would be most likely a 
replacement for caps, wouldn't it? So maybe it would be then fitting 
into the spec.

I am with John here though and IMHO the Agent Domain really should be 
split into it's individual services which all are usable independantly 
of each other.

> so.. to recap.. we (LL) have made no statement about OpenID one way or 
> another. so... don't hold your breath waiting for us to deploy services 
> that consume OpenID id services. still, it's gaining in popularity, so 
> we're not going to ignore it, we want to make sure it's properly applied 
> to the problem at hand. ditto with OAuth. ditto with SAML 1.1 / Shib 1.3.

I think we all want to have it properly applied :-) I think on this list 
we are right now also more struggling at defining "the problem at hand" ;-)

-- Christian

> On Apr 2, 2009, at 2:53 PM, Christian Scholz wrote:
> 
>> Jon Watte schrieb:
>>> Christian Scholz wrote:
>>>> Another option would be to join forces with the OAuth group at IETF 
>>>> and check on how we could add identity to OAuth (there is discussion 
>>>> about that already). Eventually this might be an easier choice and 
>>>> you could do authorization in one step, at least for some 
>>>> centralized services.
>>> The first question is: does the OAuth "callback" URL work in a VW 
>>> sense? At a minimum, this means that a VW needs to have a publicly 
>>> available *incoming* URL for receiving authentication tokens. For a 
>>> VW behind a firewall, that's not necessarily true. (Then again, OAuth 
>>> doesn't work for an intranet web site behind a firewall, either)
>>
>> The redirect setup is only one example of obtaining the OAuth token. 
>> You can do it whatever way you want to (the new version of the spec 
>> also makes that clearer as it starts with just the way you actually do 
>> authorized requests and only explains in the second part the redirect 
>> mechanism).
>>
>> But if you look at e.g. iMovie and how it uploads movies to YouTube 
>> you have an example of how a desktop app can do it (although it's not 
>> using OAuth I think but probably Google AuthSub but it's basically the 
>> same).
>>
>> Basically instead of having a callback URL the client will simply wait 
>> until the user has finished authorization in the web browser. The 
>> server then might tell him to go back to the client and click 
>> "Continue". After that the client will contact the server again and 
>> will try to exchange the request token for an access token which only 
>> will work if the user authorized it.
>>
>> I am not sure though I understand the question. You might also be 
>> talking about the server being behind a firewall and not reachable by 
>> the client. But then I guess you need some ports open anyway for the 
>> client to be able to connect any way.
>>
>> -- Christian
>>
>>
>>
>> -- 
>> COM.lounge GmbH
>> http://comlounge.net
>> Hanbrucher Strasse 33, 52064 Aachen
>> Amtsgericht Aachen HRB 15170
>> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz
>>
>> email: [e-mail]
>> fon: [phone]
>> fax: [phone]
>>
>> personal email: [e-mail]
>> personal blog: http://mrtopf.de/blog
>> personal podcasts: http://openweb-podcast.de, 
>> http://datawithoutborders.net
>>
>> _______________________________________________
>> mmox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
> 


-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: [e-mail]
fon: [phone]
fax: [phone]

personal email: [e-mail]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net