Re: Request for comments: Sorting fields in signature generation

2006-09-26 Thread Josh Hoyt
On 9/26/06, Barry Ferg [EMAIL PROTECTED] wrote: The signature generation algorithm specifies that the fields to be signed be ordered in byte order form. It seems to be implied that the ordering is based on using the field names as sorting keys I think the real topic of this discussion is

Re: Request for comments: Sorting fields in signature generation

2006-09-26 Thread Josh Hoyt
On 9/26/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Pass-through parameters are *not part of any OpenID specification.* They are not, but in order to be able to pass them through you have to be able to deal with them. Also, you may have to sign them as well. No one has written a proposal

Re: Request for comments: Sorting fields in signature generation - Call for votes

2006-09-27 Thread Josh Hoyt
On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML

Re: Request for comments: Sorting fields in signature generation

2006-09-27 Thread Josh Hoyt
On 9/27/06, Johnny Bufu [EMAIL PROTECTED] wrote: Huh? I don't see anything in that section about a requirement to echo back parameters. Not a requirement, but I read the second paragraph as implying they can/could be used. An IdP is not forbidden from echoing back any unknown parameters it

Re: featuritis for existing form handlers (was: Sorting fields in signature generation)

2006-09-28 Thread Josh Hoyt
On 9/27/06, Dick Hardt [EMAIL PROTECTED] wrote: Additionally, as we have researched what is contained in registration forms, this use case does not look like it will be that common. Many forms have some site specific data, and I am now thinking that this is not a very useful feature. I'm glad

Re: What is delegation for? (was Re: Wrapping Up Proposals)

2006-10-02 Thread Josh Hoyt
On 10/2/06, Johannes Ernst [EMAIL PROTECTED] wrote: It appears to me that OpenID should be able to do the same thing that we've been doing in LID: one-way nonces. This is the way that it's currently written up in the spec. When I wrote it up I had LID nonces in mind. The current proposal is to

Re: One last plea: fix problem with delegate terminology

2006-10-02 Thread Josh Hoyt
On 10/2/06, Drummond Reed [EMAIL PROTECTED] wrote: 2) In OpenID Authentication 2.0, define a new term to uniformly describe the concept of equivalent OpenID identifiers, i.e., identifiers that are both controlled by the same real-world authority (end user), and are mapped together to give the

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Josh Hoyt
On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote: * The IdP returns a document naming its authentication endpoint (in the URI field) and a special anonymous token as openid:Token. openid:Token may be the same as the public identifier from the previous step, but this is not required.

Delegation Proposal Amendment

2006-10-06 Thread Josh Hoyt
I'd like to amend my proposal for changing the delegation mechanism: Revised Proposal As it stands, openid.identity is the identifier by which the IdP knows the user. There is no parameter by which the RP knows the user. I propose to add a field called openid.rp_user_id in

Re: Delegation Proposal Amendment

2006-10-06 Thread Josh Hoyt
On 10/6/06, Granqvist, Hans [EMAIL PROTECTED] wrote: Can you propose this in terms of diffs to the current draft so it is glaringly obvious what the proposal means? Sure. Also, I think this diffs to current draft can be most useful for all proposals as it cuts through the various semantic

Re: Consolidated Delegate Proposal

2006-10-09 Thread Josh Hoyt
On 10/9/06, Recordon, David [EMAIL PROTECTED] wrote: In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing,

Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: RP user id is the identifier by which the relying party knows the user. This is the one that the user gave the RP? For URL identifiers, it is the supplied identifer, normalized, after following redirects. In essence, it's the user's chosen

Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: My proposal was pretty much your proposal with a couple tweaks (sorry, I should have listed these to make it clearer) - the IdP can return a different identity then the one the RP sent over I question whether this is something we want to

Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote: The IdP cannot trust the RP's discovery. The IdP will have to make sure that the IdP is authoritative for the identifier regardless. The IdP doesn't have to trust the relying party's discovery. The IdP *can* make sure that it is authoritative for

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Josh Hoyt
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: If passing through all unrecognized parameters can cause problems then there could be a special namespace for this purpose. For example, all parameters with names starting with openid.pass. should be ignored by the IdP and passed back to

Re: Delegation discussion summary

2006-10-12 Thread Josh Hoyt
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: The protocol does not need to touch on IdP-specific identifiers (aka delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will

Re: Consolidated Delegate Proposal

2006-10-13 Thread Josh Hoyt
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

Re: Identifier portability: the fundamental issue

2006-10-14 Thread Josh Hoyt
On 10/13/06, Drummond Reed [EMAIL PROTECTED] wrote: So whether it's in the spec formally or not, I don't really care. But the spec MUST contain details on the precautions a RP should take. Yup.(Got that, editors?) http://openid.net/specs/openid-authentication-2_0-10.html#anchor38 Josh

Re: Identifier portability: the fundamental issue

2006-10-14 Thread Josh Hoyt
On 10/13/06, Chris Drake [EMAIL PROTECTED] wrote: DR CASE 1: the protocol supports only IdP-specific identifiers and no portable DR identifiers. DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain),

Re: RP attack vector - why two identifiers are redundant

2006-10-14 Thread Josh Hoyt
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote: Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same

Re: Summarizing Where We're At

2006-10-16 Thread Josh Hoyt
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

2006-10-16 Thread Josh Hoyt
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

Re: Notes From Draft 10

2006-10-16 Thread Josh Hoyt
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: Notes From Draft 10

2006-10-16 Thread Josh Hoyt
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: 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

Re: Question: multiple IdPs?

2006-10-18 Thread Josh Hoyt
On 10/18/06, Dick Hardt [EMAIL PROTECTED] wrote: Thanks Drummond, but what if I am using HTML-based discovery? (that is what I am going to use in my vanity domain, much easier to implement) http://openid.net/specs/openid-authentication-2_0-10.html#html_disco HTML discovery is in there solely

Re: Question: multiple IdPs?

2006-10-19 Thread Josh Hoyt
On 10/18/06, Recordon, David [EMAIL PROTECTED] wrote: Yeah, the XML file can be based elsewhere. It is especially noteworthy that unless users are combining services, the XRDS document can be the same one that the IdP has issued to go with the IdP-specific URL. For instance, if I want to use

Re: Two Identifiers - no caching advantage

2006-10-19 Thread Josh Hoyt
On 10/19/06, Josh Hoyt [EMAIL PROTECTED] wrote: when she has control Sorry that I didn't put this all in one message, but: I think it's worthwhile to be aware of what might happen in scenarios where your identifier has been stolen, but it should not have much bearing on which proposal gets

Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-10-20 Thread Josh Hoyt
On 10/19/06, Recordon, David [EMAIL PROTECTED] wrote: The proposal we came up with was within the spec describing what to do if someone were to enter [EMAIL PROTECTED] in a Relying Party's OpenID login form. Here are the past threads that I could find about this issue: 1.

OpenID version 1.2 instead of 2.0 (Re: off topic - how many people use OpenID ?)

2006-10-20 Thread Josh Hoyt
On 10/20/06, Granqvist, Hans [EMAIL PROTECTED] wrote: I propose renaming the existing OpenID 2.0 work to be OpenID 1.2. (moved over to the specs list, since it hasn't had enough traffic lately) I think it'd be great to put what we have out as OpenID 1.2. That way, the debate and proposals here

Portable Identifier Support Proposal (patch)

2006-10-20 Thread Josh Hoyt
As requested [1], I have made a patch to the specification [2] that specifies the two-identifier mechanism for portable identifier support. It's attached to this message. The net effect is adding one line to the source XML file. I hope this proves useful in evaluating the proposal. Josh 1.

Re: Yet Another Delegation Thread

2006-10-25 Thread Josh Hoyt
On 10/25/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) Since the RP has to do discovery on the Claimed Identifier anyway, if it discovers a mapping between the Claimed Identifier and an IdP-Specific Identifier, the RP can send the IdP-Specific Identifier to the IdP and save the IdP from

Re: Yet Another Delegation Thread

2006-10-25 Thread Josh Hoyt
On 10/25/06, Dick Hardt [EMAIL PROTECTED] wrote: I have said this several times already, but THE IDP DOES NOT HAVE TO TRUST THIS INFORMATION. Then why send it? Why send which one? ___ specs mailing list specs@openid.net

Re: Yet Another Delegation Thread

2006-10-25 Thread Josh Hoyt
On 10/25/06, Pete Rowley [EMAIL PROTECTED] wrote: Is it a goal to not allow correlation of identifiers? If so, I do not think this meets that goal. Looking at the parties involved here, I necessarily have to trust my IdP, but I certainly don't want to trust RPs. So if there is to be leakage

Re: Yet Another Delegation Thread

2006-10-26 Thread Josh Hoyt
On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote: * If the IdP-specific identifier is not checked by the relying party's discovery, the IdP MUST do discovery on every request to ensure that it's not making an assertion based on stale information. Which is probably a good idea. :-) If

Re: Yet Another Delegation Thread

2006-10-26 Thread Josh Hoyt
On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote: If the IdP is not doing discovery per your previous comment, then compromising the RP's discovery is sufficient hijack a user's identifier, and it likely is easier to compromise an RP then an IdP, and we should move complexity to IdPs to an RP

Re: Went Through it With Brad

2006-11-13 Thread Josh Hoyt
On 11/8/06, Recordon, David [EMAIL PROTECTED] wrote: 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is a way to know that the IdP is using Auth 1.1. While I know we believe Yadis will be used in most applications, I hypothesize that the simplicity of HTML-based discovery

Re: [security] security hole in signature algorithm

2006-11-19 Thread Josh Hoyt
On 11/19/06, Dick Hardt [EMAIL PROTECTED] wrote: By manipulating the return_to parameter, an attacked can impersonate another user at an RP. it's hard to do a careful reading of your message with mhy 2-year-old playing piano in the background, but I don't think I understand your attack. I

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-13 Thread Josh Hoyt
On 12/12/06, Joaquin Miller [EMAIL PROTECTED] wrote: How about one of these: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body and the parameters processed MUST be only those from the POST body. When a message is sent as a POST, OpenID parameters

Re: Consistency of negative responses to checkid_immediate requests

2006-12-14 Thread Josh Hoyt
On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread Josh Hoyt
On 12/14/06, Johannes Ernst [EMAIL PROTECTED] wrote: So you believe that it is tight enough that if you and I implement the spec, and somebody types the exact same character string into both of our implementations, it will produce the exact same result, regardless what the character string

Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread Josh Hoyt
On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be

Re: Consistency of negative responses to checkid_immediate requests

2006-12-14 Thread Josh Hoyt
On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote: On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread Josh Hoyt
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 7.1 Initiation Given recent discussions on logo and User Experience, this needs to be different. Instead of: To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread Josh Hoyt
Oops, forgot to copy the list... On 12/14/06, Josh Hoyt [EMAIL PROTECTED] wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 9.1. Request Parameters ... Note: If an OP-SPecific Identifier is not supplied, the Claimed Identifier is considered to have the same as the OP

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-15 Thread Josh Hoyt
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed,

Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-15 Thread Josh Hoyt
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 10 Responding to Authentication Requests First sentence: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD identify the User-Agent, and determine whether the

Re: Consistency of negative responses to checkid_immediate requests

2006-12-26 Thread Josh Hoyt
Reviving an old thread... On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote: On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially

Re: HTML-Based Discovery with OP Identifiers

2006-12-28 Thread Josh Hoyt
On 12/28/06, David Recordon [EMAIL PROTECTED] wrote: That is a bit confusing to parse so we were looking at re-wording it. Issue is Claimed Identifier is defined as possibly being a User-Supplied Identifier which in turn can be an OP Identifier thus making this paragraph fall apart. From

Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-22 Thread Josh Hoyt
Ben, On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: OK, the idea is pretty simple. Rather like the OpenID Authentication Security Profiles you have a profile where the RP states what kind of End User/OP authentication is acceptable to it. Sites with low/zero value attached to the login can

Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-22 Thread Josh Hoyt
On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: OK, the idea is pretty simple. Rather like the OpenID Authentication Security Profiles you have a profile where the RP states what kind of End User/OP authentication is acceptable to it.

Re: HTML parsing in HTML-based discovery

2007-01-26 Thread Josh Hoyt
On 1/26/07, Martin Atkins [EMAIL PROTECTED] wrote: And, in theory, the OpenID spec could add additional restrictions to fix the above problems. Whether it should or not is of course up for debate; I'd be interested to hear from Brad Fitzpatrick and JanRain's developers who are responsible

Re: DRAFT 11 - FINAL?

2007-01-30 Thread Josh Hoyt
On 1/30/07, Recordon, David [EMAIL PROTECTED] wrote: Yeah, I'm not a big fan of openid2.* though it was the simplest method of fixing up HTML discovery to work with multiple protocol versions. I know Josh thought about this more than I did though. 1. Before authentication is initiated, the RP

Proposal: An anti-phishing compromise

2007-02-01 Thread Josh Hoyt
Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of

Re: OA2.0d11: Minor nit-pick regarding normalization

2007-02-02 Thread Josh Hoyt
On 2/1/07, Martin Atkins [EMAIL PROTECTED] wrote: The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/

Re: Proposal: An anti-phishing compromise

2007-02-02 Thread Josh Hoyt
On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That

Re: modulus and generator optional in association requests

2007-03-20 Thread Josh Hoyt
On 3/20/07, Granqvist, Hans [EMAIL PROTECTED] wrote: Once something complex is optional, typically few will implement it, which means you can run into the inverse: implementations that do supply optional values run into parties that cannot treat those values correctly. They are optional in

SREG namespace URI rollback

2007-04-02 Thread Josh Hoyt
I'd like to change the simple registration specification so that it uses the type URI that is currently in use in at least PIP and MyOpenID as the namespace URI instead of defining a new value. As far as I can tell, the only difference between the 1.0 and 1.1 simple registration specifications is

Re: SREG namespace URI rollback

2007-04-02 Thread Josh Hoyt
On 4/2/07, Johnny Bufu [EMAIL PROTECTED] wrote: I think the missing namespace in SREG1.0 can cause problems; take this example: I was not proposing that we drop the namespace. Just that we don't introduce a new URI when the protocol is otherwise identical, and instead just use the existing type

Re: Attribute Exchange pre-draft 5

2007-04-02 Thread Josh Hoyt
On 4/2/07, Rowan Kerr [EMAIL PROTECTED] wrote: On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote: What about attributes whose value could reasonably be an empty string? It would be reasonable to answer don't do that, I'm just curious how you expect this case to be handled. I'd say it's up

Re: Attribute Exchange pre-draft 5

2007-04-02 Thread Josh Hoyt
On 4/2/07, Rowan Kerr [EMAIL PROTECTED] wrote: On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote: My intuition is that a server could advertise what attributes it supports rather than including this information in a user-specific response. So, -0.5 on this. If it does go in, I'd say -1 on making

Re: SREG namespace URI rollback

2007-04-02 Thread Josh Hoyt
On 4/2/07, Recordon, David [EMAIL PROTECTED] wrote: Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves

Re: Attribute Exchange pre-draft 5

2007-04-03 Thread Josh Hoyt
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote: Since draft_4 [1] we've done some implementation and testing (as well as listened to community's suggestions on related issues), and have incorporated some changes into a pre-draft-5. Before publishing it I would like to see your comments about

Re: Attribute Exchange 1.0 svn revision 295 review

2007-04-05 Thread Josh Hoyt
On Apr 5, 2007 at 8:41 AM, Dick Hardt [EMAIL PROTECTED] wrote: There is no way to say I want as many of X as you have, and I don't care how many that is Good point. Perhaps have a magic value like -1 to indicate as many as the user will release? I had thought the RP would likely have a

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread Josh Hoyt
On 4/6/07, Dick Hardt [EMAIL PROTECTED] wrote: On 5-Apr-07, at 9:18 AM, Recordon, David wrote: I'm fine with doing things differently, I'm not arguing that a metadata format should not be created, just that IMHO for simplicity sake of reading the AX documents this format description

Re: Logout

2007-04-06 Thread Josh Hoyt
On 4/6/07, Praveen Alavilli [EMAIL PROTECTED] wrote: well with OpenID atleast, I think we can easily design a logout extension, [...] Any reason why something like this was not incorporated into the specs yet ? There is not general agreement on how this feature should be implemented, or even

Re: Attribute Exchange 1.0 svn revision 295 review

2007-04-06 Thread Josh Hoyt
On 4/6/07, Dick Hardt [EMAIL PROTECTED] wrote: I agreed with you previously that the response being able to work either way if the request can. Sorry if that was not clear. Great. That will simplify the code. Given this change, is there still the need to have the special case for sending an

Re: Logout

2007-04-06 Thread Josh Hoyt
On 4/6/07, Praveen Alavilli [EMAIL PROTECTED] wrote: I could only go only till Aug 2006 on the mail archives here: http://openid.net/pipermail/specs/ and nothing found specifically on logout' (atleast based on the thread subjects). I'd also search the other mailing lists, because the

Re: Label replacing Key

2007-04-07 Thread Josh Hoyt
On 4/7/07, Douglas Otis [EMAIL PROTECTED] wrote: This would then require all locations that use the term key when referring to a field label to be changed to label -1 If it needs to be changed, Martin's suggestion of name instead is much better. Josh

Re: encoding newlines in attribute values

2007-04-19 Thread Josh Hoyt
On 4/19/07, Marius Scurtescu [EMAIL PROTECTED] wrote: I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. Yes. The key-value encoding that's used for

Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

2007-05-17 Thread Josh Hoyt
On 5/17/07, Sam Alexander [EMAIL PROTECTED] wrote: 1. Identifier recycling. There are two different use cases for identifier recycling. The first, and the one that most people who I have talked to really want to solve is that of a large provider that wants to allow re-use of

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-17 Thread Josh Hoyt
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: There are 2 issues that I would like to see addressed. 1. Forcing Encryption, to protect users data en-route. 2. Validated assertions, validating certain bits of data with a third party. I know both of these have come up before, but have

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-17 Thread Josh Hoyt
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote: I hate to be a PITA but these issues were brought up a while ago by Eddy Nigg and Myself. I understand, but at that time, as now, I was trying to get the spec to be finished. We've been in something of an informal feature-freeze for a while.

Re: Proposal for improved security of association establishment in OpenID 2.0

2007-05-18 Thread Josh Hoyt
Guoping, I'm not an expert, but I do understand the attack that you're describing. I'm hesitant to make the change without input from Paul Crowley, who designed the key exchange mechanism in the first place. I hope that he will comment. It should be noted that a man-in-the-middle can still be a

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-18 Thread Josh Hoyt
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote: On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-18 Thread Josh Hoyt
On 5/18/07, Dmitry Shechtman [EMAIL PROTECTED] wrote: I'm sure that this will break a few implementations It certainly will break PHP-OpenID. Which implementation are you referring to as PHP-OpenID? Josh ___ specs mailing list specs@openid.net

Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

2007-05-18 Thread Josh Hoyt
Don, On 5/18/07, Don MacAskill [EMAIL PROTECTED] wrote: My company, SmugMug, is an OpenID provider for hundreds of thousands of high value paying accounts, and will shortly be a consumer as well. I'll freely admit that I haven't fully digested 2.0's pre-spec, but at least part of that reason

Re: clarifying section 11.2 in draft 11 for HTML discovery?

2007-05-24 Thread Josh Hoyt
On 5/24/07, Peter Watkins [EMAIL PROTECTED] wrote: Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? The spec as it is currently written does not support using identifier selection with HTML discovery. That was

Realm spoofing spec patch

2007-05-24 Thread Josh Hoyt
Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust.

Re: Realm spoofing spec patch

2007-05-29 Thread Josh Hoyt
Allen, On 5/29/07, Allen Tom [EMAIL PROTECTED] wrote: From an implementation perspective, it might make sense for the OP to verify the RP during the association request, so that the association handle is only returned after the RP has been verified. Were you concerned about implementation

Specifying identifier recycling

2007-05-30 Thread Josh Hoyt
Hello, I started writing up the use of fragment identifiers for URL-recycling for the OpenID 2.0 authentication spec, and I ran into some unforseen challenges. It's not obvious how a relying party should behave when a URL with a fragment is entered. How should the discovery process work? How

Re: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Josh Hoyt
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote: Since it seems no one has replied yet, I'd agree that this would make implementations easier. Iterating via a regular expression seems ugly and hard to do (well except in Perl). :-\ -1. It's one more thing to get wrong. There would then be

Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)

2007-06-05 Thread Josh Hoyt
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote: Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data,

Re: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread Josh Hoyt
On 6/5/07, Drummond Reed [EMAIL PROTECTED] wrote: I supposed this doesn't apply to large sites, where all identifiers are managed in trust for users and they can enforce non-access to previous fragments. But for personal URLs it doesn't appear to work at all. Am I missing anything? Enabling

Re: Questions about IIW Identifier Recycling Table

2007-06-07 Thread Josh Hoyt
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would

Re: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Josh Hoyt
On 6/8/07, Recordon, David [EMAIL PROTECTED] wrote: The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. I understand your concern, but I don't

Re: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Josh Hoyt
On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-11 Thread Josh Hoyt
On 6/8/07, David Fuelling [EMAIL PROTECTED] wrote: If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If I understand the way that David Recordon and Drummond are proposing that canonical identifiers

Re: The CanonicalID Approach

2007-06-11 Thread Josh Hoyt
On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote: I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent

Identifier recycling write-up on the wiki

2007-06-15 Thread Josh Hoyt
Hello, I spent some time thinking over the issues and going over the discussions that have happened about identifier recycling, and I wrote up what I understand about the issue on the OpenID.net wiki [1]. I think that my best contribution was to try to come up with as many use cases as I could

Re: Identifier recycling write-up on the wiki

2007-06-20 Thread Josh Hoyt
On 6/20/07, Chris Drake [EMAIL PROTECTED] wrote: You've got 6 points under the use cases, but it's really just 1 use case, and then 5 consequences [of] recycling. I was trying to precisely define the identifier recycling problem to which people are discussing a solution. Feel free to correct

Announce: OpenID Authentication Draft 12 (finally)

2007-08-27 Thread Josh Hoyt
by that point, we can call the spec final on October 1st. In the past, we've had timelines proposed and slipped. I don't think there's any reason for that to happen in this case, and I hope that the community will hold the editors accountable. Let's get this done! Josh Hoyt [EMAIL PROTECTED] OpenID: http

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

Re: HMAC-256 vs HMAC-SHA256 for openid.assoc_type

2007-10-31 Thread Josh Hoyt
On 10/30/07, Manger, James H [EMAIL PROTECTED] wrote: It was HMAC-SHA256 in draft 9 (10 Sep 2007), but had changed to HMAC-256 in draft 10 (13 Oct 2007). The change is looking more like a typo. Indeed, this is an error in the text. It's intended to be HMAC-SHA256. Josh

Adding fields to SREG (was: Re: SREG namespace URI rollback)

2007-11-01 Thread Josh Hoyt
On 11/1/07, David Recordon [EMAIL PROTECTED] wrote: Sorry it took me a few days, but seems alright to me. I think a larger question would be if there should be any material differences with SREG 1.1 such as adding a few additional common fields. -1 on adding anything to SREG; that's what

Errata (was Re: openid:Delegate undefined namespace)

2007-12-13 Thread Josh Hoyt
We failed to update the spec to include the OpenID 1.1 XML namespace for XRDS discovery. We should create an errata document for the OpenID 2.0 spec on openid.net and add this information. On Dec 3, 2007 9:56 PM, Manger, James H [EMAIL PROTECTED] wrote: Section 14.2.1 Relying Parties (discussing

Re: Auth 2.0 spec errata regarding delegation vs. directed identity

2008-05-21 Thread Josh Hoyt
On Wed, May 14, 2008 at 11:20 AM, Martin Atkins [EMAIL PROTECTED] wrote: * The RP, when verifying that the openid.claimed_id URL in the assertion is valid, checks only that the openid2.provider value is correct, and doesn't check that the openid2.local_id value matches (after removing the

Re: Auth 2.0 spec errata regarding delegation vs. directed identity

2008-05-21 Thread Josh Hoyt
On Wed, May 21, 2008 at 1:03 PM, John Ehn [EMAIL PROTECTED] wrote: I'm tending to agree with Martin on this one. I guess that statement does, in a roundabout way, implies the Relying Party should do the following: This is probably because I'm so familiar with the protocol and the spec, but I'm