[OpenID] OpenID For Web Services

[George Fletcher]

Paul Madsen wrote:
> Hi George, how would the main site know for which remote sites it 
> required a cert/assertion?
My assumption in the original use case, is that the "main site" is 
invoking a priori known remote sites.  The mash-up uses yahoo based 
services and hence wants to access flickr, mail and something else.

I'm skipping the case where the "main site" needs to access a user's 
unique service (e.g. the user's picture service and that service could 
be one of n services [flickr, zooomr, picassawebalbums, etc] ).  This of 
course is the more interesting case but it requires the OP to be able to 
generate the appropriate cert/assertion for that service.  And more 
importantly, it requires the services to accept the OP generated 
cert/assertion.
>
> Wouldn't the main site be more typically interested in obtaining a 
> token capturing the delegated rights for 'types' of remote service, 
> and not particular instances?
Yes... I agree that the "main site" would want to get a token that it 
could use for "types" of services.  This should be doable with the right 
set of agreed upon conventions.  However, it sort of requires the 
identifier to be the same for all services.  I think there are dangers 
in that assumption.  To solve this, the OP would need to know the 
particular instance of the service being accessed by the main site so 
that it could generate a cert/assertion with the appropriate identifier 
for that site (e.g. my zoomr OpenID is different from my mail provider 
OpenID).

Thanks,
George
>
> Paul
>
> George Fletcher wrote:
>> [Ok, if I've configured tbird correctly, this should come through to 
>> you and the general list as plain text.]
>>
>> If we go back to the original use case of a person accessing the 
>> "main site" and then the "main site" invoking remote web services on 
>> the user's behalf... it seems like this should still be doable with 
>> your certificates.
>>
>> 1. The user enters their OpenID URL at the "main site"
>> 2. The "main site" determines the OP and re-directs requesting 
>> authentication and certificates for each of the remote sites it wants 
>> to invoke (specification of certificates could use the "Attribute 
>> Exchange" extension).
>> 3. User authenticates to OP (prooveme.com) and grants consent for the 
>> requested certificates to be generated and returned to the "main 
>> site".  Note that this allows the certificates to be short-lived 
>> solving some of the certificate management issues.
>> 4. The "main site" uses the certificates to access the desired remote 
>> sites
>>
>> It seems like this model would also work using SAML Assertions as 
>> well as certificates.  There might be a nice convergence path here.
>>
>> Thanks,
>> George
>>
>> Nic James Ferrier wrote:
>>  
>>> Hi George... I had to strip your HTML so I hope I got the gist of your
>>> message. We don't all use HTML MUAs you know.
>>>
>>>
>>> George Fletcher <gffletch at aol.com> writes:
>>>
>>>    
>>>> Very interesting. Are these long term certificates?       
>>> Could be. Again, that's up to the user. I'd suggest that if a user
>>> wanted a long term relationship like:
>>>
>>>   photo site -> blog
>>>
>>>
>>> then they'd be granting that cert for a long time. They'll also be able
>>> to turn the cert off at any time.
>>>
>>>
>>>    
>>>> Will prooveme.com manage the generation of new certificates and
>>>> delivery to flickr when the old one is about to expire? or will that
>>>> be the user's responsibility?
>>>>       
>>> Yes.
>>>
>>>
>>> I'd hope that if certificates take off in anyway we can come up with
>>> more protocols, this time for distributing certificates automatically.
>>>
>>>       
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>>   
>