Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Breno de Medeiros]

I changed my mind on this one.

A. The fact that scopes are not standardized in OAuth today does not
mean that in the future *some* scopes (e.g., related to portable
contacts) may be standardized.

B. The consumer key is an intrinsic identifier of the party requesting
association and probably should be included, with the realm, in the
association request (if available).

There is no need, however, to include any additional information in
the authentication request. The consumer key can be bound to the
association handle.


On Thu, Nov 13, 2008 at 6:43 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
> In the future, we might update our OAuth service to allow developers to pass
> us the scope dynamically, rather than binding the scope to the CK. However,
> we'd still probably require developers to agree to a TOS in order to get a
> CK/CS.
>
> I'm concerned about having to tell developers to pass the CK via the scope
> parameter for the first revision, and then later telling them that scope
> parameter actually means the scope. I'd like to have one parameter (possibly
> optional) that means CK, and another parameter (also optional) that means
> Scope. Overloading a single parameter can get really messy in the long run.
>
> Allen
>
>
>
>
>
>
>
> Breno de Medeiros wrote:
>>
>> Ok, but what is wrong for you to instruct the developers to insert the
>> consumer_key in the scope parameter, and they bind it to the approved
>> request token?
>>
>
>



-- 
--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
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

In the future, we might update our OAuth service to allow developers to 
pass us the scope dynamically, rather than binding the scope to the CK. 
However, we'd still probably require developers to agree to a TOS in 
order to get a CK/CS.

I'm concerned about having to tell developers to pass the CK via the 
scope parameter for the first revision, and then later telling them that 
scope parameter actually means the scope. I'd like to have one parameter 
(possibly optional) that means CK, and another parameter (also optional) 
that means Scope. Overloading a single parameter can get really messy in 
the long run.

Allen







Breno de Medeiros wrote:
> Ok, but what is wrong for you to instruct the developers to insert the
> consumer_key in the scope parameter, and they bind it to the approved
> request token?
>   

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Breno de Medeiros]

On Thu, Nov 13, 2008 at 5:58 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
> Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is
> supposed to happen. It is probably not a good idea to return RSA keys via
> association requests for unregistered consumers though.

Ok, but what is wrong for you to instruct the developers to insert the
consumer_key in the scope parameter, and they bind it to the approved
request token?

Since each OAuth SP has defined scope differently, they will have to
look it up what to put in the scope anyway.

>
> Allen
>
>
> Breno de Medeiros wrote:
>
> 2008/11/13 Allen Tom <[EMAIL PROTECTED]>:
>
>
> In the registered consumer case, why not just do:
>
> openid.assoc_handle=consumer_key
> openid.mac_key=consumer_secret
>
>
> This implies that the consumer key is HMAC-SHA1. What if it is RSA?
>
>
>
> ?
>
> In the unregistered consumer case, the OpenID association request could be
> extended to hand out Consumer keys, which are then used as the association
> handle. The scopes and realm could be passed to the association request as
> well.
>
>
> Allen
>
>
>
> Dirk Balfanz wrote:
>
> Yes, I can see how that would happen.
>
> So how about for OPs who tie scope to Consumer Keys, their
> openid.oauth.scope syntax would look something like this:
>
> openid.oauth.scope=consumer_key:scope1,scope2,scope3
>
> Or, if there is a one-to-one mapping from consumer_key to scope, simply like
> this:
>
> openid.oauth.scope=consumer_key
>
> Dirk.
>
> On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:
>
>
> Certainly but the consumer context you display to the user is falsely
> represented based solely on the realm in that circumstance.
>
> Sent from a mobile device.
> On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
>
>
>
> On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>
>
> Dirk Balfanz wrote:
>
>
> I don't think this is true - I believe the realm is sufficient. Let me
> try and explain. (We'll assume registered consumers.) On the approval page,
> we need to identify the consumer. In its current form, the spec basically
> assumes that you're gonna use the realm for that.
>
>
> You're assuming that a realm has only one CK. A site might have multiple
> consumer keys, with different scopes attached to them...
>
>
> Actually, I wasn't assuming that. At access token request time, you follow
> the map from consumer-key to realm (that's the direction you can do, right)?
> If that's a many-to-one map then this will give you one realm. Then you
> check whether that's the realm that the request token was issued to.
>
> The one thing you're losing is that you can't, at approval time, figure
> out whether that realm is requesting a scope that they have access to. So a
> realm could ask for a certain scope in their auth request, the user approves
> it, and then at access-token-request time, you won't issue the token b/c
> they're using a CK that doesn't have enough privileges. It's still secure,
> but gives you a crappy user experience if the consumer mixes up their CKs.
>
> Wait - I think I have an idea: what if the Yahoo-specific way of
> requesting the scope is to include the CK into the openid.oauth.scope
> parameter? That way, you can at approval time make sure that they are
> requesting a scope that they are actually authorized to pick up. This
> wouldn't be for security purposes - just as a way to make sure the user
> experience isn't surprising.
>
> Dirk.
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/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
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is 
supposed to happen. It is probably not a good idea to return RSA keys 
via association requests for unregistered consumers though.


Allen


Breno de Medeiros wrote:

2008/11/13 Allen Tom <[EMAIL PROTECTED]>:
  

In the registered consumer case, why not just do:

openid.assoc_handle=consumer_key
openid.mac_key=consumer_secret



This implies that the consumer key is HMAC-SHA1. What if it is RSA?

  

?

In the unregistered consumer case, the OpenID association request could be
extended to hand out Consumer keys, which are then used as the association
handle. The scopes and realm could be passed to the association request as
well.


Allen



Dirk Balfanz wrote:

Yes, I can see how that would happen.

So how about for OPs who tie scope to Consumer Keys, their
openid.oauth.scope syntax would look something like this:

openid.oauth.scope=consumer_key:scope1,scope2,scope3

Or, if there is a one-to-one mapping from consumer_key to scope, simply like
this:

openid.oauth.scope=consumer_key

Dirk.

On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:


Certainly but the consumer context you display to the user is falsely
represented based solely on the realm in that circumstance.

Sent from a mobile device.
On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:



On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
  

Dirk Balfanz wrote:


I don't think this is true - I believe the realm is sufficient. Let me
try and explain. (We'll assume registered consumers.) On the approval page,
we need to identify the consumer. In its current form, the spec basically
assumes that you're gonna use the realm for that.
  

You're assuming that a realm has only one CK. A site might have multiple
consumer keys, with different scopes attached to them...


Actually, I wasn't assuming that. At access token request time, you follow
the map from consumer-key to realm (that's the direction you can do, right)?
If that's a many-to-one map then this will give you one realm. Then you
check whether that's the realm that the request token was issued to.

The one thing you're losing is that you can't, at approval time, figure
out whether that realm is requesting a scope that they have access to. So a
realm could ask for a certain scope in their auth request, the user approves
it, and then at access-token-request time, you won't issue the token b/c
they're using a CK that doesn't have enough privileges. It's still secure,
but gives you a crappy user experience if the consumer mixes up their CKs.

Wait - I think I have an idea: what if the Yahoo-specific way of
requesting the scope is to include the CK into the openid.oauth.scope
parameter? That way, you can at approval time make sure that they are
requesting a scope that they are actually authorized to pick up. This
wouldn't be for security purposes - just as a way to make sure the user
experience isn't surprising.

Dirk.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs







  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Breno de Medeiros]

2008/11/13 Allen Tom <[EMAIL PROTECTED]>:
> In the registered consumer case, why not just do:
>
> openid.assoc_handle=consumer_key
> openid.mac_key=consumer_secret

This implies that the consumer key is HMAC-SHA1. What if it is RSA?

>
> ?
>
> In the unregistered consumer case, the OpenID association request could be
> extended to hand out Consumer keys, which are then used as the association
> handle. The scopes and realm could be passed to the association request as
> well.
>
>
> Allen
>
>
>
> Dirk Balfanz wrote:
>
> Yes, I can see how that would happen.
>
> So how about for OPs who tie scope to Consumer Keys, their
> openid.oauth.scope syntax would look something like this:
>
> openid.oauth.scope=consumer_key:scope1,scope2,scope3
>
> Or, if there is a one-to-one mapping from consumer_key to scope, simply like
> this:
>
> openid.oauth.scope=consumer_key
>
> Dirk.
>
> On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:
>>
>> Certainly but the consumer context you display to the user is falsely
>> represented based solely on the realm in that circumstance.
>>
>> Sent from a mobile device.
>> On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>>>
>>> Dirk Balfanz wrote:

 I don't think this is true - I believe the realm is sufficient. Let me
 try and explain. (We'll assume registered consumers.) On the approval page,
 we need to identify the consumer. In its current form, the spec basically
 assumes that you're gonna use the realm for that.
>>>
>>> You're assuming that a realm has only one CK. A site might have multiple
>>> consumer keys, with different scopes attached to them...
>>
>> Actually, I wasn't assuming that. At access token request time, you follow
>> the map from consumer-key to realm (that's the direction you can do, right)?
>> If that's a many-to-one map then this will give you one realm. Then you
>> check whether that's the realm that the request token was issued to.
>>
>> The one thing you're losing is that you can't, at approval time, figure
>> out whether that realm is requesting a scope that they have access to. So a
>> realm could ask for a certain scope in their auth request, the user approves
>> it, and then at access-token-request time, you won't issue the token b/c
>> they're using a CK that doesn't have enough privileges. It's still secure,
>> but gives you a crappy user experience if the consumer mixes up their CKs.
>>
>> Wait - I think I have an idea: what if the Yahoo-specific way of
>> requesting the scope is to include the CK into the openid.oauth.scope
>> parameter? That way, you can at approval time make sure that they are
>> requesting a scope that they are actually authorized to pick up. This
>> wouldn't be for security purposes - just as a way to make sure the user
>> experience isn't surprising.
>>
>> Dirk.
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/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
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

In the registered consumer case, why not just do:

openid.assoc_handle=consumer_key
openid.mac_key=consumer_secret

?

In the unregistered consumer case, the OpenID association request could 
be extended to hand out Consumer keys, which are then used as the 
association handle. The scopes and realm could be passed to the 
association request as well.



Allen



Dirk Balfanz wrote:

Yes, I can see how that would happen.

So how about for OPs who tie scope to Consumer Keys, their 
openid.oauth.scope syntax would look something like this:


openid.oauth.scope=consumer_key:scope1,scope2,scope3

Or, if there is a one-to-one mapping from consumer_key to scope, 
simply like this:


openid.oauth.scope=consumer_key

Dirk.

On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED] 
> wrote:


Certainly but the consumer context you display to the user is
falsely represented based solely on the realm in that circumstance.


Sent from a mobile device.

On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]
> wrote:




On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]
> wrote:

Dirk Balfanz wrote:


I don't think this is true - I believe the realm is
sufficient. Let me try and explain. (We'll assume
registered consumers.) On the approval page, we need to
identify the consumer. In its current form, the spec
basically assumes that you're gonna use the realm for that.


You're assuming that a realm has only one CK. A site might
have multiple consumer keys, with different scopes attached
to them...


Actually, I wasn't assuming that. At access token request time,
you follow the map from consumer-key to realm (that's the
direction you can do, right)? If that's a many-to-one map then
this will give you one realm. Then you check whether that's the
realm that the request token was issued to.

The one thing you're losing is that you can't, at approval time,
figure out whether that realm is requesting a scope that they
have access to. So a realm could ask for a certain scope in their
auth request, the user approves it, and then at
access-token-request time, you won't issue the token b/c they're
using a CK that doesn't have enough privileges. It's still
secure, but gives you a crappy user experience if the consumer
mixes up their CKs.

Wait - I think I have an idea: what if the Yahoo-specific way of
requesting the scope is to include the CK into the
openid.oauth.scope parameter? That way, you can at approval time
make sure that they are requesting a scope that they are actually
authorized to pick up. This wouldn't be for security purposes -
just as a way to make sure the user experience isn't surprising.

Dirk.

___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Dirk Balfanz]

Yes, I can see how that would happen.

So how about for OPs who tie scope to Consumer Keys, their
openid.oauth.scope syntax would look something like this:

openid.oauth.scope=consumer_key:scope1,scope2,scope3

Or, if there is a one-to-one mapping from consumer_key to scope, simply like
this:

openid.oauth.scope=consumer_key

Dirk.

On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:

> Certainly but the consumer context you display to the user is falsely
> represented based solely on the realm in that circumstance.
>
> Sent from a mobile device.
>
> On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
>
>
>
> On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom < <[EMAIL PROTECTED]>
> [EMAIL PROTECTED]> wrote:
>
>> Dirk Balfanz wrote:
>>
>>>
>>> I don't think this is true - I believe the realm is sufficient. Let me
>>> try and explain. (We'll assume registered consumers.) On the approval page,
>>> we need to identify the consumer. In its current form, the spec basically
>>> assumes that you're gonna use the realm for that.
>>>
>>
>> You're assuming that a realm has only one CK. A site might have multiple
>> consumer keys, with different scopes attached to them...
>>
>
> Actually, I wasn't assuming that. At access token request time, you follow
> the map from consumer-key to realm (that's the direction you can do, right)?
> If that's a many-to-one map then this will give you one realm. Then you
> check whether that's the realm that the request token was issued to.
>
> The one thing you're losing is that you can't, at approval time, figure out
> whether that realm is requesting a scope that they have access to. So a
> realm could ask for a certain scope in their auth request, the user approves
> it, and then at access-token-request time, you won't issue the token b/c
> they're using a CK that doesn't have enough privileges. It's still secure,
> but gives you a crappy user experience if the consumer mixes up their CKs.
>
> Wait - I think I have an idea: what if the Yahoo-specific way of requesting
> the scope is to include the CK into the openid.oauth.scope parameter? That
> way, you can at approval time make sure that they are requesting a scope
> that they are actually authorized to pick up. This wouldn't be for security
> purposes - just as a way to make sure the user experience isn't surprising.
>
> Dirk.
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Darren Bounds]

Certainly but the consumer context you display to the user is falsely  
represented based solely on the realm in that circumstance.


Sent from a mobile device.

On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:




On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
Dirk Balfanz wrote:

I don't think this is true - I believe the realm is sufficient. Let  
me try and explain. (We'll assume registered consumers.) On the  
approval page, we need to identify the consumer. In its current  
form, the spec basically assumes that you're gonna use the realm for  
that.


You're assuming that a realm has only one CK. A site might have  
multiple consumer keys, with different scopes attached to them...


Actually, I wasn't assuming that. At access token request time, you  
follow the map from consumer-key to realm (that's the direction you  
can do, right)? If that's a many-to-one map then this will give you  
one realm. Then you check whether that's the realm that the request  
token was issued to.


The one thing you're losing is that you can't, at approval time,  
figure out whether that realm is requesting a scope that they have  
access to. So a realm could ask for a certain scope in their auth  
request, the user approves it, and then at access-token-request  
time, you won't issue the token b/c they're using a CK that doesn't  
have enough privileges. It's still secure, but gives you a crappy  
user experience if the consumer mixes up their CKs.


Wait - I think I have an idea: what if the Yahoo-specific way of  
requesting the scope is to include the CK into the  
openid.oauth.scope parameter? That way, you can at approval time  
make sure that they are requesting a scope that they are actually  
authorized to pick up. This wouldn't be for security purposes - just  
as a way to make sure the user experience isn't surprising.


Dirk.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Dirk Balfanz]

On Thu, Nov 13, 2008 at 1:58 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:

> I think so. What about cases where two descrete applications/consumers
> share a realm?
>

You think it makes sense, or that I'm missing something? :-) Anyway, are
those two applications that have nothing to do with each other? If so, then
they're probably not going to share a realm. After all, which application
are we logging the user into?

If it's the case that Allen is bringing up, and this is really the same
application just using different consumer keys for different purposes, then
I think we're fine - a mapping from consumer key to (one) realm should
suffice.

Dirk.


>
> Sent from a mobile device.
>
> On Nov 13, 2008, at 3:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
>
>
>
> On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom < <[EMAIL PROTECTED]>
> [EMAIL PROTECTED]> wrote:
>
>>  Hi Yariv,
>>
>> In the registered consumer case, the SP will need the Consumer Key to show
>> the Approval page. Previous versions of the spec had the Request Token in
>> the OpenID Authentication request, which allowed the SP to derive the
>> Consumer Key from the Request Token. At the IIW, we had discussed somehow
>> tying the Association Handle to the Consumer Key.
>>
>> Regardless of the solution, the SP will need to be know the Consumer Key
>> in order to properly identify the OAuth Consumer when displaying the
>> Approval page. The OpenID Realm is not quite sufficient, at least for SPs
>> which require consumers to pre-register for a CK.
>>
>
> I don't think this is true - I believe the realm is sufficient. Let me try
> and explain. (We'll assume registered consumers.) On the approval page, we
> need to identify the consumer. In its current form, the spec basically
> assumes that you're gonna use the realm for that.
>
> Let's assume that The Bad Guy somehow managed to sneak a misleading realm
> into a request, i.e. the user sees the realm on the login page and clicks
> "approve" when he wouldn't have approved had he known the real identity of
> The Bad Guy.
>
> The OP embeds, in the request token, the realm to which the request token
> was issued.
>
> Later, when The Bad Guy tries to exchange the request token for an access
> token, it won't work, b/c The Bad Guy only has access to his own consumer
> secret, which doesn't match the realm embedded in the request token.
>
> So we _do_ have a binding from the request token to the consumer key, it's
> just enforced later, not at approval time.
>
> Does this make sense, or am I missing something?
>
> Dirk.
>
>
>
>>
>> One possible optimization would be to just use the Consumer Key as the
>> OpenID Association Handle, and Consumer Secret as the OpenID Association.
>> The Consumer can just sign the OpenID Auth request using its CK/CS and the
>> OP can return a pre-approved response token in the OpenID assertion. The
>> Consumer can then exchange the response token for the OAuth Access Token/
>> ATS.
>>
>> Thoughts?
>> Allen
>>
>>
>>
>> Yariv Adan wrote:
>>
>> Following the IIW session on this topic, we updated the spec in
>> 
>> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto
>>  address the issues that were raised. Especially, optimizing on how OAuth
>> request token is handled, allowed to remove one full roundtrip!
>> Would appreciate any feedback on the updated suggestion.
>>
>> Thanks
>>
>> On Mon, Nov 3, 2008 at 12:00 PM, < <[EMAIL PROTECTED]>
>> [EMAIL PROTECTED]> wrote:
>>
>>> Send specs mailing list submissions to
>>> specs@openid.net
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> 
>>> http://openid.net/mailman/listinfo/specs
>>> or, via email, send a message with subject or body 'help' to
>>> <[EMAIL PROTECTED]>[EMAIL PROTECTED]
>>>
>>> You can reach the person managing the list at
>>> <[EMAIL PROTECTED]>[EMAIL PROTECTED]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of specs digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>   1. Proposal to create the OpenID OAuth Hybrid Working Group
>>>  (Yariv Adan)
>>>
>>>
>>> --
>>>
>>> Message: 1
>>> Date: Mon, 3 Nov 2008 15:30:57 +0100
>>> From: Yariv Adan < <[EMAIL PROTECTED]>[EMAIL PROTECTED]>
>>> Subject: Proposal to create the OpenID OAuth Hybrid Working Group
>>> To: specs@openid.net
>>> Message-ID:
>>>< <[EMAIL PROTECTED]>
>>> [EMAIL PROTECTED]>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>>  In accordance with the OpenID Foundation IPR policies and procedures<
>>>  
>>> http://openid.net/foundation/intellectual-property/ > this note proposes
>>> the
>>> formation of a new working group chartered to produce an Open

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Dirk Balfanz]

On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:

> Dirk Balfanz wrote:
>
>>
>> I don't think this is true - I believe the realm is sufficient. Let me try
>> and explain. (We'll assume registered consumers.) On the approval page, we
>> need to identify the consumer. In its current form, the spec basically
>> assumes that you're gonna use the realm for that.
>>
>
> You're assuming that a realm has only one CK. A site might have multiple
> consumer keys, with different scopes attached to them...
>

Actually, I wasn't assuming that. At access token request time, you follow
the map from consumer-key to realm (that's the direction you can do, right)?
If that's a many-to-one map then this will give you one realm. Then you
check whether that's the realm that the request token was issued to.

The one thing you're losing is that you can't, at approval time, figure out
whether that realm is requesting a scope that they have access to. So a
realm could ask for a certain scope in their auth request, the user approves
it, and then at access-token-request time, you won't issue the token b/c
they're using a CK that doesn't have enough privileges. It's still secure,
but gives you a crappy user experience if the consumer mixes up their CKs.

Wait - I think I have an idea: what if the Yahoo-specific way of requesting
the scope is to include the CK into the openid.oauth.scope parameter? That
way, you can at approval time make sure that they are requesting a scope
that they are actually authorized to pick up. This wouldn't be for security
purposes - just as a way to make sure the user experience isn't surprising.

Dirk.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Darren Bounds]

I think so. What about cases where two descrete applications/consumers  
share a realm?


Sent from a mobile device.

On Nov 13, 2008, at 3:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:




On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom <[EMAIL PROTECTED]>  
wrote:

Hi Yariv,

In the registered consumer case, the SP will need the Consumer Key  
to show the Approval page. Previous versions of the spec had the  
Request Token in the OpenID Authentication request, which allowed  
the SP to derive the Consumer Key from the Request Token. At the  
IIW, we had discussed somehow tying the Association Handle to the  
Consumer Key.


Regardless of the solution, the SP will need to be know the Consumer  
Key in order to properly identify the OAuth Consumer when displaying  
the Approval page. The OpenID Realm is not quite sufficient, at  
least for SPs which require consumers to pre-register for a CK.


I don't think this is true - I believe the realm is sufficient. Let  
me try and explain. (We'll assume registered consumers.) On the  
approval page, we need to identify the consumer. In its current  
form, the spec basically assumes that you're gonna use the realm for  
that.


Let's assume that The Bad Guy somehow managed to sneak a misleading  
realm into a request, i.e. the user sees the realm on the login page  
and clicks "approve" when he wouldn't have approved had he known the  
real identity of The Bad Guy.


The OP embeds, in the request token, the realm to which the request  
token was issued.


Later, when The Bad Guy tries to exchange the request token for an  
access token, it won't work, b/c The Bad Guy only has access to his  
own consumer secret, which doesn't match the realm embedded in the  
request token.


So we _do_ have a binding from the request token to the consumer  
key, it's just enforced later, not at approval time.


Does this make sense, or am I missing something?

Dirk.



One possible optimization would be to just use the Consumer Key as  
the OpenID Association Handle, and Consumer Secret as the OpenID  
Association. The Consumer can just sign the OpenID Auth request  
using its CK/CS and the OP can return a pre-approved response token  
in the OpenID assertion. The Consumer can then exchange the response  
token for the OAuth Access Token/ ATS.


Thoughts?
Allen



Yariv Adan wrote:


Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html 
 to address the issues that were raised. Especially, optimizing on  
how OAuth request token is handled, allowed to remove one full  
roundtrip!

Would appreciate any feedback on the updated suggestion.

Thanks

On Mon, Nov 3, 2008 at 12:00 PM, <[EMAIL PROTECTED]> wrote:
Send specs mailing list submissions to
   specs@openid.net

To subscribe or unsubscribe via the World Wide Web, visit
   http://openid.net/mailman/listinfo/specs
or, via email, send a message with subject or body 'help' to
   [EMAIL PROTECTED]

You can reach the person managing the list at
   [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of specs digest..."


Today's Topics:

  1. Proposal to create the OpenID OAuth Hybrid Working Group
 (Yariv Adan)


--- 
---


Message: 1
Date: Mon, 3 Nov 2008 15:30:57 +0100
From: Yariv Adan <[EMAIL PROTECTED]>
Subject: Proposal to create the OpenID OAuth Hybrid Working Group
To: specs@openid.net
Message-ID:
   <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

 In accordance with the OpenID Foundation IPR policies and  
procedures<
http://openid.net/foundation/intellectual-property/ > this note  
proposes the

formation of a new working group chartered to produce an OpenID
specification.
As per Section 4.1 of the Policies, the specifics of the proposed  
working

group are:

Background Information:
OpenID has always been focused on how to enable user-authentication  
within

the browser.  Over the last year, OAuth has been developed to allow
authorization either from within a browser, desktop software, or  
mobile

devices.  Obviously there has been interest in using OpenID and OAuth
together allowing a user to share their identity as well as grant a  
Relying
Party access to an OAuth protected resource in a single step.  A  
small group
of people have been working on developing an extension to OpenID  
which makes

this possible in a collaborative fashion within
http://code.google.com/p/step2/.  This small project includes a  
draft spec
and Open Source implementations which the proposers would like to  
finalize

within the OpenID Foundation.


Working Group Name:
OpenID OAuth Hybrid Working Group


Purpose:
Produce a standard OpenID extension to the OpenID Authentication  
protocol
that provides a mechanism to embed an OAuth approval request into  
an OpenID
authentication req

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
>
> I don't think this is true - I believe the realm is sufficient. Let me 
> try and explain. (We'll assume registered consumers.) On the approval 
> page, we need to identify the consumer. In its current form, the spec 
> basically assumes that you're gonna use the realm for that.

You're assuming that a realm has only one CK. A site might have multiple 
consumer keys, with different scopes attached to them...

Allen


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Dirk Balfanz]

On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom <[EMAIL PROTECTED]> wrote:

>  Hi Yariv,
>
> In the registered consumer case, the SP will need the Consumer Key to show
> the Approval page. Previous versions of the spec had the Request Token in
> the OpenID Authentication request, which allowed the SP to derive the
> Consumer Key from the Request Token. At the IIW, we had discussed somehow
> tying the Association Handle to the Consumer Key.
>
> Regardless of the solution, the SP will need to be know the Consumer Key in
> order to properly identify the OAuth Consumer when displaying the Approval
> page. The OpenID Realm is not quite sufficient, at least for SPs which
> require consumers to pre-register for a CK.
>

I don't think this is true - I believe the realm is sufficient. Let me try
and explain. (We'll assume registered consumers.) On the approval page, we
need to identify the consumer. In its current form, the spec basically
assumes that you're gonna use the realm for that.

Let's assume that The Bad Guy somehow managed to sneak a misleading realm
into a request, i.e. the user sees the realm on the login page and clicks
"approve" when he wouldn't have approved had he known the real identity of
The Bad Guy.

The OP embeds, in the request token, the realm to which the request token
was issued.

Later, when The Bad Guy tries to exchange the request token for an access
token, it won't work, b/c The Bad Guy only has access to his own consumer
secret, which doesn't match the realm embedded in the request token.

So we _do_ have a binding from the request token to the consumer key, it's
just enforced later, not at approval time.

Does this make sense, or am I missing something?

Dirk.



>
> One possible optimization would be to just use the Consumer Key as the
> OpenID Association Handle, and Consumer Secret as the OpenID Association.
> The Consumer can just sign the OpenID Auth request using its CK/CS and the
> OP can return a pre-approved response token in the OpenID assertion. The
> Consumer can then exchange the response token for the OAuth Access Token/
> ATS.
>
> Thoughts?
> Allen
>
>
>
> Yariv Adan wrote:
>
> Following the IIW session on this topic, we updated the spec in
> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto
>  address the issues that were raised. Especially, optimizing on how OAuth
> request token is handled, allowed to remove one full roundtrip!
> Would appreciate any feedback on the updated suggestion.
>
> Thanks
>
> On Mon, Nov 3, 2008 at 12:00 PM, <[EMAIL PROTECTED]> wrote:
>
>> Send specs mailing list submissions to
>>specs@openid.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>http://openid.net/mailman/listinfo/specs
>> or, via email, send a message with subject or body 'help' to
>>[EMAIL PROTECTED]
>>
>> You can reach the person managing the list at
>>[EMAIL PROTECTED]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of specs digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Proposal to create the OpenID OAuth Hybrid Working Group
>>  (Yariv Adan)
>>
>>
>> --
>>
>> Message: 1
>> Date: Mon, 3 Nov 2008 15:30:57 +0100
>> From: Yariv Adan <[EMAIL PROTECTED]>
>> Subject: Proposal to create the OpenID OAuth Hybrid Working Group
>> To: specs@openid.net
>> Message-ID:
>><[EMAIL PROTECTED]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>  In accordance with the OpenID Foundation IPR policies and procedures<
>> http://openid.net/foundation/intellectual-property/ > this note proposes
>> the
>> formation of a new working group chartered to produce an OpenID
>> specification.
>> As per Section 4.1 of the Policies, the specifics of the proposed working
>> group are:
>>
>> Background Information:
>> OpenID has always been focused on how to enable user-authentication within
>> the browser.  Over the last year, OAuth has been developed to allow
>> authorization either from within a browser, desktop software, or mobile
>> devices.  Obviously there has been interest in using OpenID and OAuth
>> together allowing a user to share their identity as well as grant a
>> Relying
>> Party access to an OAuth protected resource in a single step.  A small
>> group
>> of people have been working on developing an extension to OpenID which
>> makes
>> this possible in a collaborative fashion within
>> http://code.google.com/p/step2/.  This small project includes a draft
>> spec
>> and Open Source implementations which the proposers would like to finalize
>> within the OpenID Foundation.
>>
>>
>> Working Group Name:
>> OpenID OAuth Hybrid Working Group
>>
>>
>> Purpose:
>> Produce a standard OpenID extension to the OpenID Authentication protocol
>> that provides a mechanism to embed an OAuth approval request into an
>> OpenID
>> authentication request to permit combined user approval.

OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Hi Yariv,

In the registered consumer case, the SP will need the Consumer Key to 
show the Approval page. Previous versions of the spec had the Request 
Token in the OpenID Authentication request, which allowed the SP to 
derive the Consumer Key from the Request Token. At the IIW, we had 
discussed somehow tying the Association Handle to the Consumer Key.


Regardless of the solution, the SP will need to be know the Consumer Key 
in order to properly identify the OAuth Consumer when displaying the 
Approval page. The OpenID Realm is not quite sufficient, at least for 
SPs which require consumers to pre-register for a CK.


One possible optimization would be to just use the Consumer Key as the 
OpenID Association Handle, and Consumer Secret as the OpenID 
Association. The Consumer can just sign the OpenID Auth request using 
its CK/CS and the OP can return a pre-approved response token in the 
OpenID assertion. The Consumer can then exchange the response token for 
the OAuth Access Token/ ATS.


Thoughts?
Allen



Yariv Adan wrote:
Following the IIW session on this topic, we updated the spec in 
http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html 
to address the issues that were raised. Especially, optimizing on how 
OAuth request token is handled, allowed to remove one full roundtrip!

Would appreciate any feedback on the updated suggestion.

Thanks

On Mon, Nov 3, 2008 at 12:00 PM, <[EMAIL PROTECTED] 
> wrote:


Send specs mailing list submissions to
   specs@openid.net 

To subscribe or unsubscribe via the World Wide Web, visit
   http://openid.net/mailman/listinfo/specs
or, via email, send a message with subject or body 'help' to
   [EMAIL PROTECTED] 

You can reach the person managing the list at
   [EMAIL PROTECTED] 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of specs digest..."


Today's Topics:

  1. Proposal to create the OpenID OAuth Hybrid Working Group
 (Yariv Adan)


--

Message: 1
Date: Mon, 3 Nov 2008 15:30:57 +0100
From: Yariv Adan <[EMAIL PROTECTED] >
Subject: Proposal to create the OpenID OAuth Hybrid Working Group
To: specs@openid.net 
Message-ID:
 
 <[EMAIL PROTECTED]

>
Content-Type: text/plain; charset="iso-8859-1"

 In accordance with the OpenID Foundation IPR policies and procedures<
http://openid.net/foundation/intellectual-property/ > this note
proposes the
formation of a new working group chartered to produce an OpenID
specification.
As per Section 4.1 of the Policies, the specifics of the proposed
working
group are:

Background Information:
OpenID has always been focused on how to enable
user-authentication within
the browser.  Over the last year, OAuth has been developed to allow
authorization either from within a browser, desktop software, or
mobile
devices.  Obviously there has been interest in using OpenID and OAuth
together allowing a user to share their identity as well as grant
a Relying
Party access to an OAuth protected resource in a single step.  A
small group
of people have been working on developing an extension to OpenID
which makes
this possible in a collaborative fashion within
http://code.google.com/p/step2/.  This small project includes a
draft spec
and Open Source implementations which the proposers would like to
finalize
within the OpenID Foundation.


Working Group Name:
OpenID OAuth Hybrid Working Group


Purpose:
Produce a standard OpenID extension to the OpenID Authentication
protocol
that provides a mechanism to embed an OAuth approval request into
an OpenID
authentication request to permit combined user approval. The extension
addresses the use case where the OpenID Provider and OAuth Service
Provider
are the same service. To provide good user experience, it is
important to
present a combined authentication and authorization screen for the two
protocols.


Scope:
Standardize the draft Hybrid Protocol (

http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html)
as an official OpenID Extension describing how to combine an OpenID
authentication request with the approval of an OAuth request token.


Anticipated Contributions:
Draft specification referenced above and various text
contributions as more
developers implement it.


Proposed List of Specifications:
OpenID OAuth Extension 1.0. Spec completion by Q4 2008.


Anticipated audience or users of the work:
   

Re: Proposal to create the TX working group

[Nat Sakimura]

I was pointed out by Dick that "Key Exchnage" really should be "Key
Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g.

Cheers,

=nat

On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <[EMAIL PROTECTED]> wrote:

> Hi.
>
> Here is the modified version of the charter based on the discussion at IIW.
> I chose Contract Exchange instead of Contract Negotiation since detailed
> negotiation is out of scope.
>
> Cheers,
>
> =nat
>
> *Contract Exchange WG Charter (formally TX). *
>
> In accordance with the OpenID Foundation IPR policies and procedures this
> note proposes the formation of a new working group chartered to produce an
> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
> the proposed working group are:
>
>
> *Proposal*:
>
> (a)  *Charter*.
>
>  (i)  *WG name*:  Contract Exchange WG (formally Trust Exchange Extension
> (TX))
>
>  (ii)  *Purpose*:  The purpose of this WG is to produce a series of
> standard OpenID extension to the OpenID Authentication protocol that enable
> s arbitrary parties to create and exchange a mutually-digitally-signed
> legally binding "contract" that are  both broadband and mobile friendly by
> defining appropriate bindings for each use case.
>
> For this purpose, (1) public key exchange, (2) signed request and response
> based on the public keys, (3) content encryption based on public key, (4)
> extensible data transfer method, (5) contract format, (6) notification
> methods for asynchronous communications are needed to be defined. For this
> purpose, this WG will explorer the possibility of using/extending OpenID
> Attribute Exchange [AX] as well as defining new extensions where it may fit.
>
>
>
>  (iii)  *Scope*:
>
> Scope of the work
>
>-Development of the specifications including:
>
>
>- Public Key Exchange method
>   - A Public Key Cryptography based digital signature method.
>   - Legally binding contract format.
>   - Query/response communication protocols for establishing and
>   canceling of the contract.
>   - Message Encryption method to be used for the relevant
>   communications.
>   - Notification interface for asynchronous communications.
>   - Possible extension and profiling of [AX] to accommodate the above.
>
>   - Provisions for long term storage of the contracts.
>   - Conformance requirements for other data transfer protocol bindings
>
>
>- Security, threats and Risk analysis
>
>
>- Perform Security Risk analysis and profiles for best practice
>
>  Out of scope
>
>- Term negotiation: Actual negotiation of the terms of a contract
>should be dealt with out-of-band or by other specifications.
>- Assurance programs or other identity governance frameworks.
>- It is the intent that this specification be usable by any trust
>community, whether it uses conventional PKI hierarchies, peer-to-peer trust
>mechanisms, reputation systems, or other forms of trust assurance. The
>specification of any particular trust root, trust hierarchy, or trust 
> policy
>is explicitly out of scope.
>
>
>  (iv)  *Proposed* List of Specifications:  Sries of specs encompassing the
> above requirements. The actual spec may happened to be just an expansion of
> AX or several news specs as it will be determined in the WG. Expected
> completion of the first iteration is in Q1 2009.
>
>  (v)  *Anticipated audience or users of the work*:  Implementers of OpenID
> Providers and Relying Parties, especially those who require security and
> accountability features to exchange sensitive customer information (e.g.
> personally identifiable information and credit card numbers) responsibly
> among trusted parties.
>
>  (vi)  *Language* in which the WG will conduct business:  English.
>
>  (vii)  *Method of work*:  E-mail discussions on the working group mailing
> list, working group conference calls, and possibly face-to-face meetings at
> conferences.
>
>  (viii)  *Basis for determining when the work of the WG is completed*:
> Drafts will be evaluated on the basis of whether they increase or decrease
> consensus within the working group.  The work will be completed once it is
> apparent that maximal consensus on the drafts has been achieved, consistent
> with the purpose and scope.
>
> (b)  *Background Information*.
>
>  (i)  Related work being done by other WGs or organizations:
>
>- OpenID Attribute Exchange Extension 1.0 
> [AX]
>- LIberty Alliance Identity Governance Framework [IGF] 1.0 
> Draft
>- *XML Advanced Electronic Signatures [XAdES]*
>- WS-Trust 1.3 [WS-trust]
>
>- XRI 2.0 [XRI]
>- XDI 1.0 [XDI]
>- Vendor Relationship Management [VRM]
>
>
>  (ii)  Proposers:
>
>Drummond Reed, [EMAIL P

Re: specs Digest, Vol 27, Issue 3

[Yariv Adan]

Following the IIW session on this topic, we updated the spec in
http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.htmlto
address the issues that were raised. Especially, optimizing on how
OAuth
request token is handled, allowed to remove one full roundtrip!
Would appreciate any feedback on the updated suggestion.

Thanks

On Mon, Nov 3, 2008 at 12:00 PM, <[EMAIL PROTECTED]> wrote:

> Send specs mailing list submissions to
>specs@openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://openid.net/mailman/listinfo/specs
> or, via email, send a message with subject or body 'help' to
>[EMAIL PROTECTED]
>
> You can reach the person managing the list at
>[EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of specs digest..."
>
>
> Today's Topics:
>
>   1. Proposal to create the OpenID OAuth Hybrid Working Group
>  (Yariv Adan)
>
>
> --
>
> Message: 1
> Date: Mon, 3 Nov 2008 15:30:57 +0100
> From: Yariv Adan <[EMAIL PROTECTED]>
> Subject: Proposal to create the OpenID OAuth Hybrid Working Group
> To: specs@openid.net
> Message-ID:
><[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
>  In accordance with the OpenID Foundation IPR policies and procedures<
> http://openid.net/foundation/intellectual-property/ > this note proposes
> the
> formation of a new working group chartered to produce an OpenID
> specification.
> As per Section 4.1 of the Policies, the specifics of the proposed working
> group are:
>
> Background Information:
> OpenID has always been focused on how to enable user-authentication within
> the browser.  Over the last year, OAuth has been developed to allow
> authorization either from within a browser, desktop software, or mobile
> devices.  Obviously there has been interest in using OpenID and OAuth
> together allowing a user to share their identity as well as grant a Relying
> Party access to an OAuth protected resource in a single step.  A small
> group
> of people have been working on developing an extension to OpenID which
> makes
> this possible in a collaborative fashion within
> http://code.google.com/p/step2/.  This small project includes a draft spec
> and Open Source implementations which the proposers would like to finalize
> within the OpenID Foundation.
>
>
> Working Group Name:
> OpenID OAuth Hybrid Working Group
>
>
> Purpose:
> Produce a standard OpenID extension to the OpenID Authentication protocol
> that provides a mechanism to embed an OAuth approval request into an OpenID
> authentication request to permit combined user approval. The extension
> addresses the use case where the OpenID Provider and OAuth Service Provider
> are the same service. To provide good user experience, it is important to
> present a combined authentication and authorization screen for the two
> protocols.
>
>
> Scope:
> Standardize the draft Hybrid Protocol (
>
> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
> )
> as an official OpenID Extension describing how to combine an OpenID
> authentication request with the approval of an OAuth request token.
>
>
> Anticipated Contributions:
> Draft specification referenced above and various text contributions as more
> developers implement it.
>
>
> Proposed List of Specifications:
> OpenID OAuth Extension 1.0. Spec completion by Q4 2008.
>
>
> Anticipated audience or users of the work:
>  - OpenID Providers and Relying Parties
>  - OAuth Consumers and Service Providers
>  - Implementers of OpenID Providers and Relying Parties
>
>
> Language in which the WG will conduct business:
> English.
>
>
> Method of work:
> E-mail discussions on the working group mailing list and working group
> conference calls.
>
>
> Basis for determining when the work of the WG is completed:
> The work will be completed once it is apparent that maximal consensus on
> the
> protocol proposal has been achieved within the working group, consistent
> with the purpose and scope.
>
>
> Proposers:
>  - Ben Laurie, [EMAIL PROTECTED], Google
>  - Breno de Medeiros, [EMAIL PROTECTED], Google
>  - David Recordon, [EMAIL PROTECTED], Six Apart
>  - Dirk Balfanz, [EMAIL PROTECTED], Google
>  - Joseph Smarr, [EMAIL PROTECTED], Plaxo
>  - Yariv Adan, [EMAIL PROTECTED], Google  - Allen Tom, [EMAIL PROTECTED] ,
> Yahoo
>  - Josh Hoyt, [EMAIL PROTECTED] , JanRain
>
>
> Initial Editors:
>  - Dirk Balfanz, [EMAIL PROTECTED], Google  - Breno de Medeiros,
> [EMAIL PROTECTED], Google
>
>
> --
> Yariv Adan | Product Manager
> Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
> This e-mail is confidential. If you are not the right addressee please do
> not forward it, please inform the sender, and please erase this e-mail
> including any attachments. Thanks.
> -- next part -