[OpenID] unsubscribe

Erwin Boogert erwinboogert at xs4all.nl
Wed Feb 28 20:03:36 UTC 2007


Op 28-feb-2007, om 21:00 heeft general-request at openid.net het  
volgende geschreven:

> Send general mailing list submissions to
> 	general at openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://openid.net/mailman/listinfo/general
> or, via email, send a message with subject or body 'help' to
> 	general-request at openid.net
>
> You can reach the person managing the list at
> 	general-owner at openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of general digest..."
>
>
> Today's Topics:
>
>    1. Re:  OpenID For Web Services (Paul Madsen)
>    2. Re:  OpenID For Web Services (George Fletcher)
>    3. Re:  OpenID For Web Services (Stephen Paul Weber)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Feb 2007 12:19:37 -0500
> From: Paul Madsen <paulmadsen at rogers.com>
> Subject: Re: [OpenID] OpenID For Web Services
> To: George Fletcher <gffletch at aol.com>
> Cc: general at openid.net
> Message-ID: <45E5B9A9.7090802 at rogers.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi George, how would the main site know for which remote sites it
> required a 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?
>
> 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
>>
>>
>>
>
> -- 
> Paul Madsen             e:paulmadsen @ ntt-at.com
> NTT                     p:613-482-0432
>                         m:613-302-1428
>                         aim:PaulMdsn5
>                         web:connectid.blogspot.com
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 28 Feb 2007 12:59:07 -0500
> From: George Fletcher <gffletch at aol.com>
> Subject: Re: [OpenID] OpenID For Web Services
> To: Paul Madsen <paulmadsen at rogers.com>
> Cc: general at openid.net
> Message-ID: <45E5C2EB.3060106 at aol.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> 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
>>>
>>>
>>>
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 28 Feb 2007 14:31:01 -0500
> From: "Stephen Paul Weber" <singpolyma at gmail.com>
> Subject: Re: [OpenID] OpenID For Web Services
> To: "George Fletcher" <gffletch at aol.com>
> Cc: general at openid.net
> Message-ID:
> 	<6991f8e00702281131r7dbdc9aaxbba51a3ae930fbc0 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> My $.02 -- if a GET string is used to initiate it should likely be
> openid_url, since that is the field we are already suggested to accept
> for user-initiated logins (naming convention on form fields)...
>
> On 2/28/07, George Fletcher <gffletch at aol.com> wrote:
>>
>> 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
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
> -- 
> - Stephen Paul Weber, Amateur Writer
> <http://www.awriterz.org>
>
> MSN/GTalk/Jabber: singpolyma at gmail.com
> ICQ/AIM: 103332966
> BLOG: http://singpolyma.net/
>
>
> ------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> End of general Digest, Vol 6, Issue 65
> **************************************
>





More information about the general mailing list