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
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 th
When handling a bug report[1] about our PHP library[2], we encountered
an ambiguity in the spec when dealing with associate requests for
unsupported types. I've added the resolution to the spec[3] errata
page[4] on the wiki. I don't think this is a very controversial
change, but let me know if this
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" (discus
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
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
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 ar
the final draft and
blessing it as OpenID 2.0.
Do the other specification editors agree that now is the time to
declare OpenID 2.0 finished?
Josh Hoyt <[EMAIL PROTECTED]>
OpenID: http://j3h.us/
1. http://openid.net/pipermail/specs/2007-August/001953.html
2. http://openidenabled.
PR clearance 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!
Jo
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 corre
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 tha
On 6/11/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> Presumably the recommendation would be to have several identifiers
> attached to a single account just as is recommended today. I would point
> most of my identifiers at one canonical identifier but retain one or
> more special "backup identifi
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 id
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 identifi
On 6/8/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> I figure that you could potentially use the same mechanism as delegation
> to avoid the extra discovery iteration.
>
> The problem, as with delegation, is that you need to duplicate the
> endpoint URL in the source identifier's XRDS document. Th
On 6/7/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> What I'd like to markup is that my three reassignable identifiers so
> that they all use my LiveJournal userid URL as the persistent
> identifier. It should be noted that also marking them as synonyms to
> each other follows the same sort of
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
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
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 wou
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?
Ena
On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You
> > should be able to get the fragment from any relying party that you
> > visited.
>
> I believe David's point is that you cannot retrieve the fragment from
> the RP if you hav
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
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
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 shoul
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
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. Th
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 in
Claus,
On 5/20/07, Claus Färber <[EMAIL PROTECTED]> wrote:
> Peter Watkins schrieb:
> > 7.3.3 in draft 11 says
> >
> > The "openid2.provider" and "openid2.local_id" URLs MUST NOT include
> > entities other than "&", "<", ">", and """. Other characters
> > that would not be valid in the HTML docu
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
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.n
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
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 p
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.
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
On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> > There is a proposed solution that we had consensus on (Dick's
> > "fragment" proposal.)
>
> Would you please specify whom you are referring to by "we"? I understand
> that various matters are being discussed outside of this list, but shoul
On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> "aside from XRI and Yadis"? XRI alone is twice as complex as OpenID 1.1!
>
> There has been a simplification suggestion floating around since long ago:
> resolve i-names via http[s]://xri.net/.
-1. If XRI is to be included, it should be don
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
On 5/17/07, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> 5. The OpenID Auth 2.0 spec is far more complex than the 1.1 spec,
> without delivering a corresponding amount of value for the
> complexity. There is a stronger form of the complaint, which is: even
> if did deliver a corresponding amount of
OpenID 2.0 has been a work in progress for a long time. The
specification has been largely at a stand-still for long enough for
people to implement it, and even deploy it. At the Internet Identity
Workshop for the past few days, I've been talking to the people from
the OpenID community about what i
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
On 4/10/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> Since
> the main difference I'm seeing at the moment is that SREG doesn't
> specifically request each value it wants, except in openid.sreg.required
> and openid.sreg.optional.
Um, that is exactly how sreg requests each value that it wants. If
it
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
_
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 disc
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
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 ev
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 descrip
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 likel
List,
I sat down with a couple other JanRain engineers and we took a look at
the Attribute Exchange draft and recorded some issues that we have.
There are probably other smaller issues, but this is what we came up
with in a quick (?) review.
Is editing of this spec by authors of other OpenID spec
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 a
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
On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> But they are not the same -- the namespace alias can be different
> than "sreg". Are you suggesting that SREG1.1 must always use the
> "sreg" namespace alias?
They *are* the same protocol, going over different transports (that
is, embedded in dif
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 i
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
> >
On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Sorry - I may be missing something, but I still say the problem
> remains: if a SREG1.1 party builds a message with a namespace alias
> different than "sreg", it can confuse the other party which may be
> expecting specifically "sreg".
>
> Or, put
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 t
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
On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Clarified that a fetch response parameter MUST be sent for each
> requested attribute, with an empty value if the user did not supply one.
> along the lines of the above, so that the RP can fallback to
> alternative data collection meth
On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> One feature we didn't figure out yet if its benefits would be worth
> the added complexity:
> - in a fetch response, distinguish between attributes
> that the user didn't *want* to release and the ones
> not supported by t
On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Added ax.mode parameters to all messages, to unambiguously identify
> the message types; the values are:
> fetch_request
> fetch_response
> store_request
> store_response_success
> store_response_failure
On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> OpenID 2.0 has been cooking for quite a while. When
> will 2.0 be FCS?
What does FCS [1] mean?
Josh
1. http://en.wikipedia.org/wiki/FCS
___
specs mailing list
specs@openid.net
http://openid.net/m
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
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
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/
>
On 2/1/07, Paul Madsen <[EMAIL PROTECTED]> wrote:
> Hi Josh, do I understand correctly that the motivation for your proposal
> is not 'fix' the phish problem, but to simply hilite it so that RPs will
> begin to put pressure on their OPs to move to something beyond passwords?
>
> If this is the case
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 go
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, th
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
> respo
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 accept
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 logi
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
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
On 12/17/06, Manger, James H <[EMAIL PROTECTED]> wrote:
> OpenID Authentication 2.0 predraft 11 uses the "openid." prefix
> inconsistently. For instance, §5.2.3 has dot-points for "openid.mode",
> "openid.error", "openid.contact"…, whereas §5.1.2.2 has dot-points for
> "error", "contact"….
> Th
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 d
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
On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 14. Discovering OpenID Relying Parties
> >>
> >> Can I ask to append the following sentence?
> >>> The element is OPTIONAL for this use of the
> >>> element. If the element is not given, it
> >>> is assumed to be the URI on which Yadis
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
> &g
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
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
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 s
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 strin
(I will be addressing the remaining issues that you brought up one at a time)
On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 7.2 Normalization
> >>
> >> I'm not sure that this -- all of which is OPTIONAL -- should be in
> >> this document. I would suggest to either make it MANDATORY -
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
In OpenID 2.0, we have removed the "setup_url" parameter from negative
responses to "checkid_immediate" requests. This means that a negative
response to a "checkid_immediate" request looks like:
http://rp.com/return_to?openid.mode=id_res&openid.ns=[OpenID 2.0 ns]
A negative response to a "checkid
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, OpenI
On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> It is unclear which of those parameters are MANDATORY and which
> >> are OPTIONAL
Thanks for your detailed reading and feedback. I'm not commenting in
this message about any specific point that you have, but just pointing
out that RFC2119
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 d
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 discov
On 11/10/06, Prasanta Behera <[EMAIL PROTECTED]> wrote:
> #1: Section 10.1
> > Value: Comma-separated list of signed fields. Note: This entry consists of
> the fields without the "openid." prefix that the signature covers. This list
>
> > MUST contain at least "return_to" and "response_nonce", and
On 10/26/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> On 26-Oct-06, at 8:27 AM, Josh Hoyt wrote:
> > Requiring this discovery adds another (redundant) HTTP request to the
> > authentication process, which takes time. I'd like to be able to
> > improve the "Us
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
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.
On 10/25/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> Nothing prevents you from routing all of those into a single in-box ;-)
Although it can be hard to mentally keep the context of the
discussion, and to keep appropriate discussion on the appropriate
list. A usability discussion that affects s
On 10/25/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> > Then why send it?
>
> That's what I've been asking all along! :)
>
> What exactly do we imagine the IdP doing with the claimed_identifier?
> The main answer I've seen anyone post so far is that the IdP will use it
> to greet the user
The pr
On 10/25/06, Pete Rowley <[EMAIL PROTECTED]> wrote:
> Josh Hoyt wrote:
> > If the user uses different IdP-specific identifiers for each portable
> > identifier, I don't see how they can be correlated.
>
> Unless I mis-understand the the OpenID discovery mechani
On 10/25/06, Pete Rowley <[EMAIL PROTECTED]> wrote:
> > The IdP can issue as many identifiers as it wants to the user, and the
> > user can use a different IdP-specific identifier for each of their
> > separate portable identifiers.
>
> I don't understand why this would help - it really doesn't mat
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
> l
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
http://openid.net/ma
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
> > t
On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> 2) the RP does not verify the binding between the portable
> identifier and the IdP-specific identifier in the response.
> to the one the attacker controls and the IdP has mapped
This is the part where I think you're wrong. The RP MUST
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. ht
1 - 100 of 170 matches
Mail list logo
