Re: Changing Terminology (was RE: IdP term in spec (was RE: Delegation discussion summary))

2006-10-17 Thread Dick Hardt
I think we should be open (pun intended) to making changes.

I really like the OpenID Provider - shortens to OP, and is very  
specific on what it does.
I have always found IdP to be a misnomer, and have mentioned it in  
the past.
Now we have a great candidate, that provides more clarity, and it  
should be a simple search and replace, and does not affect any code.

Agreed the user friendly terms may take some more discussion.

-- Dick

On 15-Oct-06, at 11:58 AM, Recordon, David wrote:

 I'd really prefer not to change terminology in the spec right now.
 Seems like something we should have thought about four months ago  
 versus
 a week after we said it would be final.  There is nothing saying user
 friendly terms that map to spec terms can't be created for the time
 being.  I do however think there will need to be healthy discussion
 around them, that takes longer than a week.  :)

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Drummond Reed
 Sent: Saturday, October 14, 2006 11:43 PM
 To: 'Johannes Ernst'; specs@openid.net
 Subject: IdP term in spec (was RE: Delegation discussion summary)

 Suggestion: sidestep the issue completely and in the spec -- and
 everywhere else -- just call it OpenID provider. It's a simple
 concatenation of OpenID and service provider, so everyone gets it,
 but nobody will associate it with SAML or federation or anything else.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Johannes Ernst
 Sent: Saturday, October 14, 2006 11:37 PM
 To: specs@openid.net
 Subject: Re: Delegation discussion summary

 We call it identity host at NetMesh. It's close enough to identity
 provider so people understand it quickly, but does not have the
 provider part to it (duh).

 On Oct 14, 2006, at 20:46, Scott Kveton wrote:

 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

 As per my last email I feel the same way about identity provider
 as well
 ... I agree with Dick; too overloaded and not user friendly.

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

 Johannes Ernst
 NetMesh Inc.


 ___
 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: Pre-Draft 11

2006-10-17 Thread Prasanta Behera
The example in section 4.1.3 does not match.

mode:error
error:This is an example message

openid.mode=erroropenid.err

Should it be openid.mode:error? (Ouch!)
I think = instead of : is better.

Thanks,
/Prasanta


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Tuesday, October 17, 2006 3:24 AM
To: specs@openid.net
Subject: Pre-Draft 11

Over the past few days I've gone through and done a lot of cleanup on
the draft to add clarity and reword awkward paragraphs.  No actual
content changes should have been made between Draft 10 and this draft.
Figure this is a better benchmark when looking at the remaining
proposals than Draft 10.

--David

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


Re: Identifier portability: the fundamental issue

2006-10-17 Thread Dick Hardt

On 16-Oct-06, at 12:24 PM, Martin Atkins wrote:

 Chris Drake wrote:

 There seem to be a lot of people on this list who want to hate and
 loathe the IdP, and grant all power to the RP.  I do not understand
 this reasoning:  our users will select the IdP they trust and like,
 then they will be using a multitude of possibly hostile RPs
 thereafter: the reverse is simply not true.


 If I'm using one IdP to assert my primary public identity, they can
 hypothetically develop quite a profile about me. I probably don't mind
 too much in most cases, because I researched them and found that they
 are a good provider and won't sell my data out to the bad guys.

 However, there might be some things I want to do (for example, posting
 locally-prohibited speech on a public forum) that I don't want  
 attached
 in any way, shape or form to my public identity. The trust  
 relationship
 I have with that IdP probably isn't enough for this; if there is any
 record at all of any association between these two identities, as
 friendly as my IdP may be, there is a chance that it will be ceased by
 court order, or leaked by an insider, which might lead to me  
 getting in
 serious legal trouble.

 This is just one (perhaps extreme) example of why my trust in my  
 IdP is
 not universal and all-encompassing. Trust is not a boolean.

A possible solution is you can use a different IdP when you want to  
do this activity so there is no link to your primary IdP.

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


Re: Consolidated Delegate Proposal

2006-10-17 Thread Dick Hardt

On 13-Oct-06, at 3:43 PM, Josh Hoyt wrote:

 On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The IdP is issuing a signed assertion about these identifiers, I
 would assume the IdP to check the link between these identifiers.

 Sending two identifiers does not *prevent* the IdP from checking to
 make sure they match.

 What if a bad RP sends an auth request with a mismatched set and then
 re-posts the response to some other RP? I am sure someone will figure
 a way to exploit this.

 It is, and must be, the relying party's responsibility to ensure that
 the information in the response matches what is discovered. This is
 true regardless when portable identifiers are used and when they are
 not. It is true for all of the proposed delegation mechanisms. It is
 really one of the fundamental elements of OpenID.

 A response from an IdP is meaningless until it is compared with the
 discovered information for the identifier in question.

If the RP is needing to make sure they match, then what is the point  
in sending both since the RP is figuring them out anyway?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Summarizing Where We're At

2006-10-17 Thread Dick Hardt

On 16-Oct-06, at 11:21 AM, Josh Hoyt wrote:


 * Bare Request
  - Proposed, no discussion yet.

 -0 (YAGNI)

Sorry, I don't know what YAGNI means ...

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


Re: Summarizing Where We're At

2006-10-17 Thread Dick Hardt

On 15-Oct-06, at 7:25 PM, Recordon, David wrote:

 Hi Chris,
 The rush is that 2.0 has been in a drafting phase for almost six  
 months
 now, with draft five being posted at the end of June.  While we
 certainly can continue taking the time to make everyone happy, we
 ultimately will never have a finished specification.

While I am keen to have the draft done, I don't think we started  
having a good discussion within the community until mid-September.

While we can not make everyone happy, we do need to have rough  
consensus.

-- Dick

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


Re: Identifier portability: the fundamental issue

2006-10-17 Thread Hans Granqvist
Drummond Reed wrote:
 I think you may have me mistaken for somebody else on the list (. . .)

Double-blind anonymity in action? ;)


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


Re: Summarizing Where We're At

2006-10-17 Thread Josh Hoyt
On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote:
   * Authentication Age
- Re-proposed today adding clarity in motivation, general
   consensus is
   needed to add to specification.
  
   -1
 
  There is no reason for this to be in the core. I could make more
  arguments about it, but I'll stop there, unless there is consensus
  that it should go in the core.

 Would you provide a reason to counter my justification:
 http://openid.net/pipermail/specs/2006-October/000433.html

 Your vote is a -1, not a zero, so I would like to understand why.

The way that I understand your argument is it has something to do
with authentication, so put it in the core spec. Features should be
in an extension if it can be, so that the spec is easier to
understand, implement, and extend. Especially if there is not
consensus.

I am also not convinced that it's technically the right way to
accomplish what you're aiming to accomplish, but I am not going there
unless you can convince enough people that the use case is in scope
for core OpenID authentication.

Also:
  http://openid.net/pipermail/specs/2006-October/000206.html

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


Re: Re[2]: Identifier portability: the fundamental issue

2006-10-17 Thread Kevin Turner
On Tue, 2006-10-17 at 13:29 +1000, Chris Drake wrote:
 Now - how comfortable are you with
 the idea of letting 1.5 billion Chinese people use OpenID

Ideally we'd have the input of the SocialBrain Foundation on that.
Those are the folks who put together OpenID.cn.  Has anyone on this list
talked to them at all?


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


Re: Consolidated Delegate Proposal

2006-10-17 Thread Dick Hardt
I don't see there being general consensus.

I think Chris Drake was supportive of there being less disclosure as  
well.

Josh said it could be any of the three, but preferred two parameters.

Brad did not really care.

I do care and would like to see direct criticism on the explanation I  
wrote about how the protocol works.

It is a different way of thinking about what OpenID is doing, and I  
think it is a useful view that makes it simpler. The RP does not need  
to worry about the delegation mechanism. There is only one identifier  
moving around. The concept that there is an RP identifier and an IdP  
identifier is not needed.

What is missing from my previous posts? Throw me a bloody bone here  
so that I know what I am missing.

-- Dick


On 17-Oct-06, at 3:20 PM, Recordon, David wrote:

 I'm also echoing what Josh has said.  There has been significant
 discussion on this issue and there seems to be general consensus,
 excluding Sxip, that the protocol should have two parameters.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Josh Hoyt
 Sent: Tuesday, October 17, 2006 5:24 PM
 To: Dick Hardt
 Cc: specs@openid.net
 Subject: Re: Consolidated Delegate Proposal

 On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote:
 2. It is explicit what is going on from an implementation and
 specification perspective

 And I see the opposite. What the RP sends the IdP is just a hint.
 What the IdP sends the RP is authoritative.
 I see having two parameters as implying more meaning then is really
 there.

 The IdP sending two identifiers *in the response* as the important  
 part.
 The IdP is only authoritative *if discovery says it is*. There is no
 more meaning to the response than I am asserting that when you do
 discovery, you will find that this information is true. What other
 meaning do you see?

 Did you read what I wrote? Was there something you did not  
 understand?

 Perhaps you can point out what you disagree about what I wrote?

 It's possible that I misinterpreted the RP is figuring them out
 anyway. I took this as questioning why two identifiers is an
 improvement over the current (delegate only) model.

 My answer to this question was it is explicit what is going on  
 from an
 implementation and specification perspective. This statement was
 motivated by implementation experience and experience writing about  
 this
 issue in OpenID 2 drafts. I believe that the two identifier approach
 will be easier.

 I also believe that if I had spent the time that I've spent arguing
 about this issue in documentation and implementation, the world  
 would be
 better off, regardless of which of the three viable options for
 identifier portability had been chosen.

 I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for  
 all of
 them. You know which trade-offs I'd make. I know which ones you'd  
 make.
 We just need to make a decision so that we can spend our energy and  
 time
 on things that will make a difference to end-users. This is my last  
 word
 on this list about this issue, unless there is significant insight.  
 I am
 not going to change my votes.

 If you want to discuss it more off-list, I'm willing, but I think  
 that'd
 just be wasting both of our time.

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



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