Re: More questions about openid.ax.update_url

2007-10-22 Thread James Henstridge
On 18/10/2007, Johnny Bufu [EMAIL PROTECTED] wrote:
 Hi James,

 On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

  I have a few more questions about the update_url feature of OpenID
  attribute exchange that I feel could do with answers in the
  specification.
 
  For the questions, imagine an OpenID RP with the following properties:
 
  1. The RP provides a unified login/signup workflow, so that if a user
  signs in with a previously unused OpenID a new account is created.
 
  2. The RP does not manage any user details, instead requesting them
  via attribute exchange during login, and through updates provided via
  the openid.ax.update_url protocol.

 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

What I meant was that the RP would act as a cache for the user details
stored in the OP.

So the RP would not provide a form letting the user change their
profile details, instead advising them to make the changes at their
OP.  The changes would then be communicated back to the RP via an
update_url message.


 Maybe I'm not understanding the flow and what the RP is supposed to
 do with a new value sent to the update_url.

It'd update the cached user details stored by the RP.


  3. Some portion of users enter an OP identifier URL into the login
  page on the RP (i.e. they are using directed identity).
 
  4. The RP does not want to ask the user to authenticate twice, even if
  they are creating an account.
 
 
  With this setup, it is highly likely that the RP will send multiple
  openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

Here, I meant that the RP is likely to send multiple authentication
requests with openid.ax.mode=fetch_request and openid.ax.update_url
fields, since it doesn't know that it has already asked for updates
for the particular identity.


  For standard authentication requests, the RP will know whether it has
  previously requested updates, but in the directed identity case we
  don't know what claimed ID will be picked at the time of making the
  request.  So in some cases the RP will ask for updates for an OpenID
  that they are already receiving updates for.
 
  So the question is what should an OP do if it receives multiple
  requests for updates for a particular claimed identifier with the same
  ax.update_url or realm value?  Should it treat the latest request as
  superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

Okay, that is good to know.  It seems like a good reason not to
include a transaction ID or similar in the update_url like the
example in the specification then.

If the two requests for updates ask for different sets of attributes
(as might happen after upgrading the software on the RP), could the OP
decide to throw out the old update request, or should it send updates
for the union of the two requests?

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


Re: OpenID 2.0 finalization progress

2007-10-22 Thread Dick Hardt

On 19-Oct-07, at 10:20 PM, David Recordon wrote:

 Completely agreed with Johannes.  We are very close with the IPR
 policy/process being in place and assuming all the contributors agree
 to it, 2.0 can be declared final within 30 days of October 30th as
 that is the end of the public review period for the policy.  2.0 is
 really important and has a wide range of contributors, we've all put
 a lot of effort into this, lets make sure we do this right.

Doing it right would have been to have had a process in place over a  
year ago. A little late to be doing it right now. Now we are having  
to clean up the mess!


 To Kevin's question, the IPR policy does not require a patent search,
 which as he points out could be a lengthy process.  Rather it
 requires that all contributors to the specification make a non-
 assertion statement to ensure that the spec truly is free and not
 encumbered by any patents.

Just because the contributors all make non-assertion statements does  
not make the spec unencumbered. Non-contributors could have patents  
that are asserted.

While having an IPR policy in place will, provide more certainty  
around the IPR, it will NOT ensure the spec is free.


 I spoke with Brad Fitzpatrick (cc'd)
 tonight about this and he too agrees that 2.0 should not be declared
 final until it has gone through the IPR review cycle to fully ensure
 that it is clear from any IPR encumbrances in regards to the
 contributors.

You forgot to not cc Brad, and I'd prefer to hear from Brad himself  
then have you channel him.

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


RE: OpenID 2.0 finalization progress

2007-10-22 Thread Gabe Wachob
Dick is right here regarding the certainty that an IPR policy provides with
respect to patent. 

And IPR policy can never ensure that everyone in the world will refrain from
making patent claims. With regards to patent, an IPR policy and procedure
can only really affect those who choose to be subject to it, either
passively by participating in a standards process, or actively by issuing a
license or non-assert. 

So Dick is right that it's not 100% protection - but it does at least
demonstrate that those directly involved are not attempting to induce
implementations which are covered by patent claims for which patent holders
intend to demand royalties or impose other unacceptable restrictions on use.

  -Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Dick Hardt
 Sent: Monday, October 22, 2007 2:44 AM
 To: [EMAIL PROTECTED]
 Cc: specs@openid.net
 Subject: Re: OpenID 2.0 finalization progress
 
 
 On 19-Oct-07, at 10:20 PM, David Recordon wrote:
 
  Completely agreed with Johannes.  We are very close with the IPR
  policy/process being in place and assuming all the contributors agree
  to it, 2.0 can be declared final within 30 days of October 30th as
  that is the end of the public review period for the policy.  2.0 is
  really important and has a wide range of contributors, we've all put
  a lot of effort into this, lets make sure we do this right.
 
 Doing it right would have been to have had a process in place over a
 year ago. A little late to be doing it right now. Now we are having
 to clean up the mess!
 
 
  To Kevin's question, the IPR policy does not require a patent search,
  which as he points out could be a lengthy process.  Rather it
  requires that all contributors to the specification make a non-
  assertion statement to ensure that the spec truly is free and not
  encumbered by any patents.
 
 Just because the contributors all make non-assertion statements does
 not make the spec unencumbered. Non-contributors could have patents
 that are asserted.
 
 While having an IPR policy in place will, provide more certainty
 around the IPR, it will NOT ensure the spec is free.
 
 
  I spoke with Brad Fitzpatrick (cc'd)
  tonight about this and he too agrees that 2.0 should not be declared
  final until it has gone through the IPR review cycle to fully ensure
  that it is clear from any IPR encumbrances in regards to the
  contributors.
 
 You forgot to not cc Brad, and I'd prefer to hear from Brad himself
 then have you channel him.
 
 -- Dick
 ___
 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: More questions about openid.ax.update_url

2007-10-22 Thread Johnny Bufu

On 22-Oct-07, at 3:23 AM, James Henstridge wrote:
 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

 What I meant was that the RP would act as a cache for the user details
 stored in the OP.

 So the RP would not provide a form letting the user change their
 profile details, instead advising them to make the changes at their
 OP.  The changes would then be communicated back to the RP via an
 update_url message.

That's a possibility, but I think it would be poor user experience  
for the RP to tell the user in plain text go to the OP and then come  
back.

Attribute Exchange also has a store message: the user can update  
their data at the RP, and if the RP thinks that piece of data may be  
useful in other places it can 'store' it at the OP (user has to  
confirm etc, but the whole process is specified and can be automated).

 3. Some portion of users enter an OP identifier URL into the login
 page on the RP (i.e. they are using directed identity).

 4. The RP does not want to ask the user to authenticate twice,  
 even if
 they are creating an account.


 With this setup, it is highly likely that the RP will send multiple
 openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

 Here, I meant that the RP is likely to send multiple authentication
 requests with openid.ax.mode=fetch_request and openid.ax.update_url
 fields, since it doesn't know that it has already asked for updates
 for the particular identity.

If it's a stateless RP, then I agree - there can be some overhead.

Otherwise, the RP can use the browser session (or even a  
transaction_id in the return url) to keep track of which user is  
which, what data was requested for each one etc. So not really a AX  
protocol issue as I see it.


 For standard authentication requests, the RP will know whether it  
 has
 previously requested updates, but in the directed identity case we
 don't know what claimed ID will be picked at the time of making the
 request.  So in some cases the RP will ask for updates for an OpenID
 that they are already receiving updates for.

 So the question is what should an OP do if it receives multiple
 requests for updates for a particular claimed identifier with the  
 same
 ax.update_url or realm value?  Should it treat the latest request as
 superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

 Okay, that is good to know.  It seems like a good reason not to
 include a transaction ID or similar in the update_url like the
 example in the specification then.

 If the two requests for updates ask for different sets of attributes
 (as might happen after upgrading the software on the RP), could the OP
 decide to throw out the old update request,

The OP should throw it away only when it receives a 404 on the  
update_url.

 or should it send updates for the union of the two requests?

As the user updates their data at the OP, the OP can optimize the  
updates it sends out (as long as they match the requests and the user  
has approved them).


Johnny

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


Re: OpenID 2.0 finalization progress

2007-10-22 Thread Kevin Turner
On Fri, 2007-10-19 at 16:12 -0700, Johannes Ernst wrote:
 [...] and after they had produced a spec, Rambus said but we have
 some patents. This lead to at least one lawsuit I believe.
 
 I have heard wildly diverging assessments on whether or not this  
 could happen here.

Ok, I'm looking for the devil's advocate here, so let's assume the
worst.  Say we call the spec final now, and then sometime in the next
forty days, a problem like that comes up.  What are the consequences of
that?  Specifically, do any of the solutions to that hypothetical
problem involve changing the spec?  In what way?

The way I understand it, right now one of two things happens:

1) Things go more-or-less smoothly now.  The IPR policy may get tinkered
with a little bit during the review period but this does not influence
the technical specification.

2) The sky falls and we decide that there is no IPR policy that can
possibly cover the current specification, so we must change the
specification.  Given our track record at publishing new drafts, this
means that we wouldn't be final until _at least_ Q1 2008, if not Q2.

...

It is Very Bad if I believe #2 is probable.  Thus I would prefer to
believe it is _not_ possible, leaving me with only #1.  And #1 has no
negative consequences to calling the spec final _now_.

Am I mischaracterizing the situation here?



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


An OAuth OpenID Extension

2007-10-22 Thread David Recordon
Hey all,
I know John did some work in September (http://extremeswank.com/ 
openid_trusted_auth.html and http://extremeswank.com/ 
openid_inline_auth.html).  Both solve extremely important use-cases  
and are becoming increasingly discussed especially with the advent of  
OAuth.  I'd really like to see how we can work to write an extension  
to OpenID Authentication where the OpenID Provider is also the one  
handling OAuth credentials.  This would be useful in the inline  
authentication use case as well as if we move to a deployment  
scenario where the OAuth Provider is checking with the user's OpenID  
Provider to verify OAuth signatures.  Overtime I also think moving  
OpenID to the OAuth signature mechanism would be beneficial, but I  
think that is a longer conversation.

--David

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


Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread David Recordon
Agreed with Jonathan here, don't think we need to define a policy URI  
for active.  Rather need to clarify what is meant in section 5.1.
(Optional) If the End User has not actively authenticated to the OP  
within the number
of seconds specified in a manner fitting the requested policies, the  
OP MUST
authenticate the End User for this request.

What about?
Active authentication is defined as the user providing a credential  
to the OP beyond a cookie which passively stores prior authentication  
credentials.

Still don't like that definition, but hopefully a few iterations and  
we'll get there.  Also asking around in the security community if  
there is a definition for this.

--David

On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:


 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:

 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.  Thus
 # if there isn't agreement on a policy, there would be multiple  
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.

 Agreed. PAPE spec should define one such policy that's acceptable  
 for most of the OPs/RPs (and tie auth_age to it), leaving the  
 possibility open for anyone to define other similar policies.

 This could be a bit tricky to specify if there's another parameter  
 involved, but we should be able to come up with a solution.

 Johnny




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


Re: PAPE Extension Specification (part 2)

2007-10-22 Thread David Recordon

On Oct 9, 2007, at 10:08 AM, Jonathan Daugherty wrote:

 Hi all,

 Here are a few more items.

 Section 5.1

   - The spec doesn't specify what should be done in the absence of
 max_auth_age in a PAPE request.  I could assume, but it would be
 easy enough to specify, say, that the OP is to authenticate the
 user at its own discretion.

Works for me.  http://svn.openid.net/diff.php? 
repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=372sc=1


   - In my opinion, the third paragraph for max_auth_age (beginning
 The OP should realize) is implicit.  I think it should be
 removed.

I could be convinced either way.  Personally I lean toward leaving it  
since it provides additional context as to the parameter.  All of  
PAPE is a negotiation dance between the RP and OP, so also inferring  
that a RP may or may not choose to deny access to the user is important.


   - The preferred_auth_policies specification claims, If multiple
 policies are requested, the OP SHALL try to satisfy as many as it
 can.  In terms of language strength, SHALL try is an oxymoron.
 Can we change this to If multiple policies are requested, the OP
 SHOULD satisfy as many as possible?

Good catch.  http://svn.openid.net/diff.php? 
repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=372sc=1

   - The preferred_auth_policies specification also states that If no
 policies are requested, the RP is interested in other information
 such as the authentication age.  I think that is speculative and
 should be removed.  If it isn't removed, I think it should be
 moved to a section discussing the protocol flow more generally.


I've moved it down under the Value: line which is where most other  
notes are.  If there is somewhere else to put it entirely that is  
good too.  Been trying to augment the parameters with a note so that  
it is easy to get context all in one place.  http://svn.openid.net/ 
diff.php?repname=specificationspath=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xmlrev=374sc=1

Thanks,
--David

 Thanks,

 -- 
   Jonathan Daugherty
   JanRain, Inc.
   irc.freenode.net: cygnus in #openid
   cygnus.myopenid.com
 ___
 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 2.0 finalization progress

2007-10-22 Thread Gabe Wachob


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Kevin Turner
 Sent: Monday, October 22, 2007 1:34 PM
 To: specs
 Subject: Re: OpenID 2.0 finalization progress
 
 On Fri, 2007-10-19 at 16:12 -0700, Johannes Ernst wrote:
  [...] and after they had produced a spec, Rambus said but we have
  some patents. This lead to at least one lawsuit I believe.
 
  I have heard wildly diverging assessments on whether or not this
  could happen here.
 
 Ok, I'm looking for the devil's advocate here, so let's assume the
 worst.  Say we call the spec final now, and then sometime in the next
 forty days, a problem like that comes up.  What are the consequences of
 that?  Specifically, do any of the solutions to that hypothetical
 problem involve changing the spec?  In what way?

Typically, the community would choose to remove or change the part of the
spec which ostensibly infringed upon claims raised by a patentholder. This
could be major or it could be minor. Can't tell until someone raises a
patent claim. 

 The way I understand it, right now one of two things happens:
 
 1) Things go more-or-less smoothly now.  The IPR policy may get tinkered
 with a little bit during the review period but this does not influence
 the technical specification.
 
 2) The sky falls and we decide that there is no IPR policy that can
 possibly cover the current specification, so we must change the
 specification.  Given our track record at publishing new drafts, this
 means that we wouldn't be final until _at least_ Q1 2008, if not Q2.

The third possibility is the real concern (that Johannes is referring to):

3) the community calls the spec final and a contributor raises a potential
patent infringement issue, and since the community has already implemented
and deployed 2.0, the patent owner has more leverage because the costs of
engineering around the claims in the patent have gone way up because of
already-deployed software. 

I'm not saying #3 is likely - but that's the scenario we are trying to
prevent. 

-Gabe


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


Re: Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread Paul Madsen
SAML 2.0 expresses it in terms of whether or not the authentication is 
'passive'

paul

David Recordon wrote:
 Agreed with Jonathan here, don't think we need to define a policy URI  
 for active.  Rather need to clarify what is meant in section 5.1.
   (Optional) If the End User has not actively authenticated to the OP  
 within the number
   of seconds specified in a manner fitting the requested policies, the  
 OP MUST
   authenticate the End User for this request.

 What about?
   Active authentication is defined as the user providing a credential  
 to the OP beyond a cookie which passively stores prior authentication  
 credentials.

 Still don't like that definition, but hopefully a few iterations and  
 we'll get there.  Also asking around in the security community if  
 there is a definition for this.

 --David

 On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:

   
 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:

 
 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.  Thus
 # if there isn't agreement on a policy, there would be multiple  
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.
   
 Agreed. PAPE spec should define one such policy that's acceptable  
 for most of the OPs/RPs (and tie auth_age to it), leaving the  
 possibility open for anyone to define other similar policies.

 This could be a bit tricky to specify if there's another parameter  
 involved, but we should be able to come up with a solution.

 Johnny


 


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


   

-- 
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com 

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


Re: Question about PAPE

2007-10-22 Thread David Recordon
Hey Siddharth,
Just to be clear, a OTP hardware token is considered a one-time  
password device token not a Hard token given SP 800-63, section 6  
on page 15.  This means that a OTP device can satisfy up to level 3,  
though a FIPS compliant Hard token would be needed for level 4.

Level 3 also requires two-factor authentication, so OTP plus at least  
a password or pin.  On page 37, it gives the example of a one-time  
password device combined with a Level 1 password transmitted via TLS.

When replying with a NIST level, the OP can only include one value.   
Thus if 0, 1, 2 and 3 are possible, the OP should decide which level  
it wishes to respond with.  While 3 may be the strongest, there may  
be situations where you instead want to respond with a lower values.

Yes, per the PAPE abstract it does not talk about enrollment or  
identity proofing.

--David

On Oct 12, 2007, at 3:36 PM, Bajaj, Siddharth wrote:


 Hi David,

 I have a quick question about the PAPE draft specification. In the
 response parameters, you can set a parameter called
 'openid.pape.nist_auth_level'

 There is a section 7.1.2 that describes the paramter and in the last
 table the spec maps some of the common authentication technologies to
 the NIST levels.

 Now for example, lets take an OTP hardware token, which satisfies the
 requirements for Levels 1, 2, and 3. So, should the OP set the  
 value of
 the parameter to the highest level that it satisfies (in this case  
 3) or
 does the OP individually list all the auth levels it meets (in this  
 case
 1,2,3). This is not clear From the table or the spec. Given that the
 barcelona interop is coming up, can you clarify.

 Also, the NIST levels typically take into account the authentication
 credential as well as id proofing. I'm guessing that for the  
 purposes of
 PAPE we are ignoring the initial ID vetting/id proofing requirements.
 Thanks,

 Siddharth


 ___
 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: Defining PAPE active authentication (WAS: Re: PAPE Extension Specification)

2007-10-22 Thread David Recordon
Hey Paul,
How do you guys define passive.  Seems like the opposite problem of  
defining active.

Thanks,
--David

On Oct 22, 2007, at 3:18 PM, Paul Madsen wrote:

 SAML 2.0 expresses it in terms of whether or not the authentication  
 is 'passive'

 paul

 David Recordon wrote:
 Agreed with Jonathan here, don't think we need to define a policy  
 URI  for active.  Rather need to clarify what is meant in  
 section 5.1.
  (Optional) If the End User has not actively authenticated to the  
 OP  within the number
  of seconds specified in a manner fitting the requested policies,  
 the  OP MUST
  authenticate the End User for this request.

 What about?
  Active authentication is defined as the user providing a  
 credential  to the OP beyond a cookie which passively stores prior  
 authentication  credentials.

 Still don't like that definition, but hopefully a few iterations  
 and  we'll get there.  Also asking around in the security  
 community if  there is a definition for this.

 --David

 On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote:


 On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:


 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.   
 Thus
 # if there isn't agreement on a policy, there would be multiple   
 policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.

 Agreed. PAPE spec should define one such policy that's  
 acceptable  for most of the OPs/RPs (and tie auth_age to it),  
 leaving the  possibility open for anyone to define other similar  
 policies.

 This could be a bit tricky to specify if there's another  
 parameter  involved, but we should be able to come up with a  
 solution.

 Johnny





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




 -- 
 Paul Madsen e:paulmadsen @ ntt-at.com
 NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com



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


Re: OpenID 2.0 finalization progress

2007-10-22 Thread Josh Hoyt
On 10/22/07, Gabe Wachob [EMAIL PROTECTED] wrote:
 3) the community calls the spec final and a contributor raises a potential
 patent infringement issue, and since the community has already implemented
 and deployed 2.0, the patent owner has more leverage because the costs of
 engineering around the claims in the patent have gone way up because of
 already-deployed software.

In order for this to be a concern, there needs to be a party who currently:
 1. has a patent that the spec infringes upon
 -- and --
 2. intends to claim infringement it if the spec is released without
an IPR agreement in place
 -- and --
 3. would be party to the IPR agreement

Did I get this right?

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


RE: OpenID 2.0 finalization progress

2007-10-22 Thread Gabe Wachob
I think that's exactly right, though it's really easy to have blind spots
when it comes to figuring out the permutations of how one can game group
behavior... so I won't guarantee anything else could happen (I've learned
that much from law school ;)

As I said, I *believe* the all the actors involved wish to work in the
community's best interest - though my belief in the goodness of humanity
doesn't really carry any legal meaning!!!

-Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
 Hoyt
 Sent: Monday, October 22, 2007 3:29 PM
 To: Gabe Wachob
 Cc: Kevin Turner; specs
 Subject: Re: OpenID 2.0 finalization progress
 
 On 10/22/07, Gabe Wachob [EMAIL PROTECTED] wrote:
  3) the community calls the spec final and a contributor raises a
 potential
  patent infringement issue, and since the community has already
 implemented
  and deployed 2.0, the patent owner has more leverage because the costs
 of
  engineering around the claims in the patent have gone way up because
 of
  already-deployed software.
 
 In order for this to be a concern, there needs to be a party who
 currently:
  1. has a patent that the spec infringes upon
  -- and --
  2. intends to claim infringement it if the spec is released without
 an IPR agreement in place
  -- and --
  3. would be party to the IPR agreement
 
 Did I get this right?
 
 Josh

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


Some PAPE Wording Clarifications

2007-10-22 Thread David Recordon
Hey Johnny and Jonathan,
Just checked in some clarifications, review would be appreciated.   
http://openid.net/pipermail/commits/2007-October/000381.html

Thanks,
--David

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


Re: An OAuth OpenID Extension

2007-10-22 Thread Joseph Holsten
Wow, these are neat. Thanks for the links david, and especially the  
work john!

OK, so the Inline Auth use case seems like a straightforward case for  
OAuth: resource url = identifier,  user auth url = delegate.  
Successfully accessing the resource after negotiation would imply  
that the user still trusts the RP. Seems like low hanging fruit.  
Also, gets the benefit of single sign off!

I'm a little unsure about the best way for the Trusted Auth use case.  
This seems quite good, but a diagram of an oauth solution to the  
problem was on the mailing list not long ago. Same as the official  
diagram, but with a third column showing interactions between the  
Consumer Directs User to Service Provider and Service Provider  
Directs User to Consumer steps. I looked for half an hour, found  
nothing, but I'm not crazy really! Anyway, it would be nice to  
compare perspectives first.

But if I remember correctly, the oauth proposal only allowed the  
Service Provider/Destination Consumer to revoke resource access,  
while openid trusted auth gives that right to the OP. Greater  
overhead versus greater user control.

So who's interested in fleshing out these recommendations into specs?

http:/ joseph holsten .com


On 02007:10:22, at 3:54CDT, David Recordon wrote:

 Hey all,
 I know John did some work in September (http://extremeswank.com/
 openid_trusted_auth.html and http://extremeswank.com/
 openid_inline_auth.html).  Both solve extremely important use-cases
 and are becoming increasingly discussed especially with the advent of
 OAuth.  I'd really like to see how we can work to write an extension
 to OpenID Authentication where the OpenID Provider is also the one
 handling OAuth credentials.  This would be useful in the inline
 authentication use case as well as if we move to a deployment
 scenario where the OAuth Provider is checking with the user's OpenID
 Provider to verify OAuth signatures.  Overtime I also think moving
 OpenID to the OAuth signature mechanism would be beneficial, but I
 think that is a longer conversation.

 --David

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

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