Re: Discussion: RP Yadis URL?

Recordon, David wrote: I'm torn if this parameter should be added to the spec at this time or not. Adding the parameter is conceptually simple, though I don't think there is agreement on what the RP should be publishing in their Yadis file. There is the section

Re: Re[2]: [PROPOSAL] request nonce and name

On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote: Also note that URL parameters are not secured by TLS in HTTPS. -- Dick URL parameters are sent with the path in the GET line of the HTTP request after the TLS handshake, so URL parameters ARE secured. -- Grant Monroe JanRain, Inc.

Re: Identifier portability: the fundamental issue

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:

Re: Summarizing Where We're At

Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into

Re: Identifier portability: the fundamental issue

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

Re: Identifier portability: the fundamental issue

On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: In this case you are better off opening a separate account with this or some other IdP. The current delegation model will not protect you at all. The delegate tag is in a publicly accessible Yadis document. I agree that anonymity is an

Notes From Draft 10

While I've already incorporated many of the things I found in draft 9 into 10, there were a few things which I didn't either have the right answer to or feel that I could make the change on my own. I tried reading through the draft as if I was reading it for the first time. 4.2 Integer

RE: Identifier portability: the fundamental issue

+1. Trust is not a boolean. Martin, that's very quotable. Can I attribute it to you? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Monday, October 16, 2006 12:25 PM To: specs@openid.net Subject: Re: Identifier

Re: Notes From Draft 10

On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. I think it's

Re: Notes From Draft 10

On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Sorting by UTF-8-encoded octet sequence is easy. Why would be an

RE: Summarizing Where We're At

And here are my votes: Request nonce and name * Take no action Authentication age * -1, write as an extension first Remove setup_url * 0 for removing, +1 for asking feedback from implementers Consolidated Delegation Proposal * -1 on status quo (draft 10) * 0 on single-identifier * +1 on

Re: Notes From Draft 10

Marius Scurtescu wrote: On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of

Re: Notes From Draft 10

On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote: On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Sorting by UTF-8-encoded

RE: Summarizing Where We're At

I want to avoid the wait-I-thought-we-decided-something-else or ahh-yes-seems-we-forgot-it-had-an-impact-there delays . . . Spec work gain tremendously by unambiguous up-front definitions of what *exactly* is voted on. A good way to do this is to force the vote to be on an explicit

Re: Notes From Draft 10

On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. If ordering is not important then you are guaranteed to get it right.

Re[2]: Identifier portability: the fundamental issue

Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an

RE: Summarizing Where We're At

My votes on three issues (0 on everything else): Consolidated Delegation Proposal * -1 on status quo (draft 10) * +1 on two-identifier Change default session type * +1 Bare request * +1 =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of

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

Chris, I think you may have me mistaken for somebody else on the list (DR is also David Recordon). I'm a big fan of IdP-initiated login and privacy protection in OpenID. However as much as I think that's an important use case, there's also many use cases around using a public, omnidirectional