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

[Dirk Balfanz]

Thanks! Fixed.

Dirk.

On Thu, Nov 20, 2008 at 6:37 AM, Paul Madsen <[EMAIL PROTECTED]> wrote:

>  Dirk, typo in Sec 6
>
> The Combined Provider SHOULD in addition obtain, from the Combined
> Provider, a list .
>
> paul
>
> Dirk Balfanz wrote:
>
> Ok, new spec is up:
> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
>
> Dirk.
>
> On Mon, Nov 17, 2008 at 5:40 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
>
>> [+Brian Eaton]
>>
>>  On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>>
>>> Sadly, because the OpenID authentication request is not signed, the CK
>>> can't be authenticated, but as you pointed out, although the user may
>>> authorize the application, the CK secret is still required to fetch the
>>> credentials. The worst that could happen is that a user will authorize an
>>> impostor, but the impostor will not be able to retrieve the token.
>>>
>>> That being said, in our case, the CK contains additional information
>>> besides the scope. Yahoo's OAuth Permissions screen contains a lot of rich
>>> information including the application's name, description, developer(s),
>>> images, authorization lifetimes, etc. Over time, new fields may be added to
>>> the approval page.
>>>
>>> While it might make sense for the application's scope to be passed in at
>>> authorization time, does it also make sense to define new parameters for all
>>> the other application specific metadata? The actual data that needs to be
>>> displayed on an approval page is very SP specific, and some SPs may have
>>> security/legal policies requiring that all metadata is manually reviewed,
>>> which makes it impossible for metadata to be passed in at runtime.
>>>
>>
>> Oh I see. Ok. I'l make a new revision of the spec where I add a required
>> parameter (the consumer key) to the auth request.
>>
>> What should the spec recommend the OP should do if the consumer key and
>> realm don't match? Return a cancel? Return something else?
>>
>> Another change I'll be making is to take out references to unregistered
>> consumers. Brian found a weakness in our approach (the one where we make the
>> association secret the consumer secret) that makes me think we need to think
>> about unregistered consumers a bit more[1].
>>
>> Dirk.
>>
>> [1] Basically, the problem is that we have oracles around the web that add
>> OAuth signatures to arbitrary requests. They're called OpenSocial gadget
>> containers. If and when OpenID signatures and OAuth signatures converge,
>> with the current propocal we might end up in a situation where my gadget
>> container will create OAuth signatures using the same key needed to assert
>> auth responses.
>>
>>
>>
>>> So that's why SPs may need the CK in order to display the Approval page.
>>> Make sense?
>>>
>>> Allen
>>>
>>>
>>>
>>> Dirk Balfanz wrote:
>>>

 Need to know the CK for what? What purpose would hinting at the CK serve
 (since it wouldn't prove ownership)? And don't say "scope" :-)


>>>
>>
> --
>
> ___
> specs mailing [EMAIL PROTECTED]://openid.net/mailman/listinfo/specs
>
> --
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.549 / Virus Database: 270.9.6/1797 - Release Date: 18/11/2008 
> 11:23 AM
>
>
>
> --
> [image: ConnectID] 
>
<>___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Paul Madsen]

Dirk, typo in Sec 6

The Combined Provider SHOULD in addition obtain, from the Combined
Provider, a list .

paul

Dirk Balfanz wrote:
Ok, new spec is up: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
  
Dirk.
  
  On Mon, Nov 17, 2008 at 5:40 PM, Dirk
Balfanz <[EMAIL PROTECTED]>
wrote:
  [+Brian
Eaton]


On Mon, Nov 17, 2008 at 4:31 PM, Allen Tom <[EMAIL PROTECTED]>
wrote:

Sadly, because the OpenID authentication request is not signed, the CK
can't be authenticated, but as you pointed out, although the user may
authorize the application, the CK secret is still required to fetch the
credentials. The worst that could happen is that a user will authorize
an impostor, but the impostor will not be able to retrieve the token.
  
That being said, in our case, the CK contains additional information
besides the scope. Yahoo's OAuth Permissions screen contains a lot of
rich information including the application's name, description,
developer(s), images, authorization lifetimes, etc. Over time, new
fields may be added to the approval page.
  
While it might make sense for the application's scope to be passed in
at authorization time, does it also make sense to define new parameters
for all the other application specific metadata? The actual data that
needs to be displayed on an approval page is very SP specific, and some
SPs may have security/legal policies requiring that all metadata is
manually reviewed, which makes it impossible for metadata to be passed
in at runtime.



Oh I see. Ok. I'l make a new revision of the spec where I add a
required parameter (the consumer key) to the auth request. 

What should the spec recommend the OP should do if the consumer key and
realm don't match? Return a cancel? Return something else?

Another change I'll be making is to take out references to unregistered
consumers. Brian found a weakness in our approach (the one where we
make the association secret the consumer secret) that makes me think we
need to think about unregistered consumers a bit more[1]. 

Dirk.
 
[1] Basically, the problem is that we have oracles around the web that
add OAuth signatures to arbitrary requests. They're called OpenSocial
gadget containers. If and when OpenID signatures and OAuth signatures
converge, with the current propocal we might end up in a situation
where my gadget container will create OAuth signatures using the same
key needed to assert auth responses. 





So that's why SPs may need the CK in order to display the Approval
page. Make sense?
  
Allen
  
  
  
  
  
Dirk Balfanz wrote:
  

Need to know the CK for what? What purpose would hinting at the CK
serve (since it wouldn't prove ownership)? And don't say "scope" :-)

  
  
  
  




  
  
  
  

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.549 / Virus Database: 270.9.6/1797 - Release Date: 18/11/2008 11:23 AM
  


-- 



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