Agreed that it makes sense to split it out when the underlying work (XRD
1.0) is ready.
=Drummond
_
From: David Recordon [mailto:drecor...@sixapart.com]
Sent: Sunday, January 04, 2009 11:24 PM
To: Drummond Reed
Cc: sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs
I'm just catching up on holiday mail and wanted to add another +1 to
separation of Discovery from AuthN. The sooner the better.
=Drummond
_
From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf
Of David Fuelling
Sent: Friday, December 26, 2008 8:47 AM
To: Nat
/ Signatures
(XAdES)
(ii) Proposers:
Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A)
Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark)
Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan)
John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada
Shade, here's the nut of the problem: directed identity in OpenID
Authentication 2.0 means nothing more than:
The user logging in to your site is not asserting the URI they have typed
in; instead the OP will tell you the URI for the user.
Then _any_ URI then returned from the OP *is* then the
George Fletcher wrote:
I think relying party sites that support OpenID could do more to make
it
clear on their home pages that they support OpenID (as often it's
hidden
behind another click). This could be as simple as some link tags that
advertise support for OpenID. Maybe a link to
-Original Message-
From: Noah Slater [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 1:43 AM
To: Drummond Reed
Cc: specs@openid.net
Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
Noah, you are in the right place (and the General list is the wrong
place
mailing list suggesting this is something that needs
attention on the call this week.
=Drummond
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad
Fitzpatrick
Sent: Monday, March 10, 2008 11:01 AM
To: Drummond Reed
Cc: Noah Slater; specs@openid.net; [EMAIL
-Original Message-
From: David Recordon [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 12:15 PM
To: Drummond Reed; Brad Fitzpatrick
Cc: Noah Slater; OpenID specs list; DeWitt Clinton
Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14
I don't see why changes would really
FYI - XRI Resolution 2.0 is now undergoing one more 15-day public review
after incorporation of feedback from the previous 60-day public review in
December and January. Links to both the change-marked and clean version of
the spec are in the announcement below.
=Drummond
-Original
+1. Since the results would apply to both URLs and XRIs, I expect several
XRI TC members would be willing to help review such guidelines.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of John Ehn
Sent: Friday, January 25, 2008 3:34 PM
To:
attribute. Figured OpenID in the next rev of the spec should talk more
about implementation details.
-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 11:57 PM
To: McGovern, James F (HTSC, IT); specs@openid.net
Subject: RE
James, are you asking about the recommended format for saving an OpenID
identifier in an LDAP directory? If so, I know Boeing has done some work in
that area -- I can check with their directory guru.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism,
specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0
Committee Draft 02
(http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
), deals with DNS poisoning by using signed SAML
Phillip, what do you mean by Until the IPR commitments necessary to allow
that change are made there is no standard. The OASIS XRI TC has operated
under a royalty-free IPR policy since the day it was formed (see the
language in the charter,
http://www.oasis-open.org/committees/xri/charter.php),
+1 to Nat's point about supporting virtual aggregation under user control.
Chris, on the larger question you ask, the Data Sharing Summit was not about
how others that have your data can share it, but rather about how you can
control and share that data the way you want with whom you want.
To be
Multiple, redundant identifiers is what canonical ID mapping provides. It
doesn't require a master directory; it's as distributed as OpenID itself,
i.e., it simply provides a way to map a reassignable URL or XRI to a
persistent URL or XRI.
Given the right practices, it solves both A and B. The
Dick Hardt wrote:
Canonical IDs do not solve B.
I would agree with that one.
Obviously the XRI architecture assumption (not as radically
decentralized as OpenID) makes that less of a problem in an XRI
context. Of course, some would say that that assumption is a problem
in itself.
Drummond Reed wrote:
Multiple, redundant identifiers is what canonical ID mapping
provides. It
doesn't require a master directory; it's as distributed as OpenID
itself,
i.e., it simply provides a way to map a reassignable URL or XRI to a
persistent URL or XRI.
Dick Hardt wrote
Johnny Bufu wrote:
We did look at this (with Drummond) in December. The bottom line is
that it can't be done easily - a mechanism similar to XRI's canonical
ID verification would have to be employed, to confirm that the i-
number actually 'belongs' to the URL on which discovery was
-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 7:52 PM
To: Recordon, David
Cc: Drummond Reed; OpenID specs list
Subject: Re: Review of Yadis section in XRI Resolution 2.0 WD11
On 31-May-07, at 5:34 PM, Recordon, David wrote:
I'd recommend adding
John Panzer wrote:
Has there been a discussion about an extension to map to/from i-
numbers
via AX? If there were a generic attribute you could stuff an i-
number
or a hash of an internal ID in there to help solve the disambiguation
problem. Alternatively it'd be nice to have a way to
Johannes:
What about the point Dick posted earlier in this thread, that the problem
with using a public key is if the private key gets compromised? Persistent
identifiers need to persist independent of any attribute changing or being
revoked.
=Drummond
-Original Message-
From: [EMAIL
As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and
vote on the XRI Resolution 2.0 spec (which has been at the Working Draft 10
stage during the entire evolution of OpenID Authentication 2.0) so it can be
referenced by OpenID Authentication 2.0 when it goes final.
To that
Johnny Bufu wrote:
While at IIW, I asked around what people thought about the encoding
mechanisms we've added recently, in order to allow for transferring
any data types. The consensus was that everyone would prefer
something simpler and lighter.
So I've rewritten the encoding section,
Peter Watkins wrote:
snip
My concrete suggestion: replace the current language
Other characters that would not be valid in the HTML document or that
cannot be represented in the document's character encoding MUST be escaped
using the percent-encoding (%xx) mechanism described in [RFC3986].
On 9-Apr-07, at 5:24 PM, Recordon, David wrote:
Yes, I agree an upgrade path from SREG is needed. We could however do
something as simple as
http://openid.net/specs/openid-simple-registration-
extension-1_0.html#ni
ckname for the existing SREG fields.
Dick wrote:
by making this a
+1 as well. Very well articulated.
An interesting side note: XRI supports a # fragment for backward
compatibility with URI/IRI syntax, but in practice its rarely used since XRI
syntax is already polyarchical, i.e., any XRI can be put in the context of
another XRI. # is just one such context
Kevin Turner wrote:
Sorry it took me a few months to notice this, but xri://$dns? No. I'm
referring here to spec rev 274, the diff for which is attached. Can we
roll that patch back, please?
I'm not even sure where you're getting an XRI Syntax 2.1 reference from,
there's not so much as a
+1 to defining attribute identifier URIs/XRIs in the Identity Commons ID
Schemas project.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Wednesday, April 04, 2007 1:16 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject:
I've always been supportive of breaking out OpenID Discovery into a separate
spec. I wouldn't break it out into separate specs, however, because
discovery for any OpenID identifier has have much more in common than they
have different. For example, they all need to explain the relationship of
the
Drummond Reed wrote:
Under this approach, discovery all identifiers (URLs, XRI
i-names/i-numbers,
email addresses, phone numbers, etc.) would be handled by OpenID
Discovery.
Martin Atkins wrote:
I disagree that a single spec can contain discovery rules for all
conceivable discovery types
David,
Great wiki page -- this is the kind of resource that really helps work
through issues like this.
On the issue itself, I need more time to think it through.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David Fuelling
Sent: Saturday,
at the i-brokers.
=Drummond
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman
Sent: Wednesday, January 03, 2007 11:38 PM
To: Drummond Reed
Cc: Recordon, David; openid-general; specs@openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net
the issue Johnny brought up, and also properly support the
use of multiple i-name (or HXRI) synonyms for the same i-number.
=Drummond
-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 11:34 PM
To: Drummond Reed; Bob Wyman; openid
Just FYI, the xmldsig KeyInfo element is already part of the XRD schema
because the XRI Resolution spec uses it in the SAML form of trusted XRI
resolution. And either the SAML form or the HTTPS form of XRI trusted res
can give you the security characteristics in the Key Discovery spec.
That said,
: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 10:35 PM
To: Drummond Reed; Carl Howells; Grant Monroe
Cc: specs@openid.net
Subject: RE: Key Discovery In DTP Draft 3
Oooh, interesting...
So looking at working draft 10
http://www.oasis-open.org/committees/download.php/17293
Bob, it's a great question, and David's correct as far as he goes, and so is
Johnny. However I suspect that the behaviour you're experiencing is due to
older OpenID libraries being used by the RP site at which you're
experiencing this behaviour.
Here's why: if you entered your i-name =bobwyman in
Welcome, James. I have a special interest in this topic due to my work on
XDI (XRI Data Interchange) at OASIS. I'm happy to help figure out how it can
be applied here.
+1 to Dick's suggestion to just keep the posts modular, i.e., short on-topic
threads that can be discussed individually.
Avery,
Paul's the one to weigh in on this option - he wrote (and lived) the book on
SAML AuthN Context. But I do like the looks of what you proposed - seems
very elegant.
=Drummond
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Avery Glasser
Sent: Thursday,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Watkins
Sent: Wednesday, November 08, 2006 4:21 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Recordon, David wrote:
it -- just noting that the same software
component in an actual deployment can be seen in various lights and
have multiple names (roles!).)
FWIW,
Eve
John Kemp wrote:
Hi Drummond,
Drummond Reed wrote:
So why, indeed, is there so much interest in OpenID? I believe it's
because
My understanding is that the concern is with potential conflicts in the
actual functioning of openid.net.
Creating a clean DNS namespace for specs at specs.openid.net does seem like
a good solution to me.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
David, in the message below, I assume you meant to say return_to is
NOW an optional parameter... instead of return_to is
NOT an optional parameter That's the only way I can make sense of it.
Am I right?
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I want to clear up what I believe are two misconceptions about the proposed
terminology change (both in the specs and across all the OpenID
educational/marketing materials) from Identity Provider (IdP) to OpenID
Provider (OP). (Note that these are my personal views and may not be shared
by others
+1. In this whole discussion, I have three very strong views (which the
editors can take as input into their call today):
1) If RP discovery reveals an IdP-specific identifier, the RP MUST send it
to the IdP because that's what the IdP needs most to serve the user.
2) If the IdP receives an
Hardt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 24, 2006 10:07 PM
To: Drummond Reed
Cc: 'Recordon, David'; specs@openid.net
Subject: Re: Yet Another Delegation Thread
Thanks for the explanation Drummond. I think we need a con call on
this topic alone ... :-)
On 24-Oct-06, at 6:16 PM
,
talking this over more with Josh and Drummond it doesn't actually
accomplish all of the goals anyway.
--David
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 23, 2006 11:04 PM
To: Drummond Reed
Cc: Recordon, David; specs@openid.net
Subject: Re
Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 9:26 AM
To: Drummond Reed
Cc: 'Recordon, David'; 'Martin Atkins'; specs@openid.net
Subject: Re: XRI confusion
That provides clarity on the process, thanks. If the user knows that
their i-name has been
In the directed identity case, the IdP URL or XRI you give to the RP
resolves to your IdP's XRDS document. Each of your IdPs would have a
different one. If they support directed identity, each would have a Service
with a Type tag value of http://openid.net/identifier_select/2.0. This
service
I don't think anything is missing from your previous posts, nor do I think
you've missed anything from other's previous posts. I think we've discussed
this issue thoroughly from all sides.
As you say, It is a different way of thinking about what OpenID is doing.
In other words, it's a worldview
+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
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
identifier. So OpenID
should accommodate both.
=Drummond
-Original Message-
From: Chris Drake [mailto:[EMAIL PROTECTED]
Sent: Monday, October 16, 2006 8:29 PM
To: Drummond Reed
Cc: 'Martin Atkins'; specs@openid.net
Subject: Re[2]: Identifier portability: the fundamental issue
Hi Drummond
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-
Chris,
I totally agree that: a) OpenID Authentication 2.0 should support yours
scenario of IdP-initiated login, and b) that this enables a whole range of
privacy solutions, many of which can be supported by IdP innovation.
If IdP-initiated login were the only use case, then only one identifier
Hans,
This has come up a few times and the mapping between the portable identifier
and the IdP-specific identifier is available in public XRDS documents. So
there's no point in trying to hide that information from the IdP -- and it
may even be misleading to suggest to end-users that they could
But I suggest we move that terminology discussion to the marketing list.
What marketing list?
http://lists.iwantmyopenid.org/mailman/listinfo/marketing.
=Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Martin wrote:
I think this is the intention, though it does show an interesting
inconsistency between the use of XRIs and the use of i-numbers. I
currently have three URL-based identifiers all pointing at the same
server and the same Yadis document, yet those identifiers are distinct.
Marius wrote:
I was suggesting that portability can be resolved between the user
and
the IdP. I cannot see how the protocol can help this by passing two
identifiers. And if only the portable identifier is passed then
there is
no need to mention the IdP-specific identifier.
Marius,
Yesterday we established consensus that with OpenID, identifier portability
is sacred.
Today I'd like to establish consensus on the following postulate:
To achieve identifier portability in OpenID, it MUST be possible for the RP
and the IdP to identify the user using two different identifiers:
Drummond wrote:
To achieve identifier portability in OpenID, it MUST be
possible for the RP and the IdP to identify the user using
two different identifiers: an identifier by which the RP
knows the user (the portable identifier), and an identifier
by which the IdP knows the user (the
+1. Josh, you did a great job of not just distilling it down to the essence,
but also nailing the right semantics for the underlying feature, which is
identifier portability.
Nice work.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh
+1 to Josh's point. IMHO identifier portability is sacred. If anyone
disagrees, please post, can we assume we have consensus on this?
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 8:56 PM
To: Marius
Title: RE: Delegation discussion summary
+1 to getting it done. This area of
terminology is more a usability/marketing issue at this point. I agree we need to
converge on good, simple user-facing terms for describing OpenID in ways ordinary
Web users can easily understand. Although I have
.
=Drummond
-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 9:38 AM
To: Drummond Reed; specs@openid.net
Subject: RE: Consolidated Delegate Proposal
In terms of openid.display, shouldn't the IdP greet the user in whatever
manner it uses
Dick,
While I think I followed most of what you say here, I'm not sure what the
exact proposal is. Are you proposing to remove the openid:delegate element
in 2.0? And replace it with an indirect identifier request protocol (your
step 3 below)?
=Drummond
-Original Message-
From: [EMAIL
Johannes Ernst wrote:
Drummond:
The current auth draft says in section 11.4:
If the Verified Identifier is an XRI, the discovered CanonicalID
field from the XRD SHOULD be used as a key for local storage of
information about the End User.
Is there ever a scenario where the
Martin wrote:
I'm surprised that our resident privacy advocates aren't making a
bigger
deal out of this. (If the privacy advocates have no problem then I'll
let this go, since this isn't a use case I feel particularly strongly
about myself.)
Dick wrote:
I was supportive of keeping the
On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:
Again, this is why I recommend RPs don't even store the i-name, but
instead
store their own display name for the user. The display name and the
i-number
(CanonicalID) never need to change, whereas an i-name may be
reassigned.
Dick
Drummond wrote:
Better still, if you could add it to the end of
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and
explain
how the same motivations and use cases currently covered there
(using two
identifier parameters) can be satisfied just using openid.identity,
On 10/10/06, Dick Hardt wrote:
[openid.rpuserid is the identifier] that the user gave the RP?
Josh Hoyt wrote:
For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen identifier.
For XRI identifers, it's the canonical ID
Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 9:34 AM
To: Drummond Reed; specs@openid.net
Subject: RE: Consolidated Delegate Proposal
Ok, that makes it more clear.
I think this line was part of what was throwing me, If Claimed
Identifier is EITHER
, October 09, 2006 2:21 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; specs@openid.net
Subject: Re: Delegation Proposal Amendment
Drummond
How does the RP get a persistent identifier before it has called the
IdP? The user could type anything into the form.
-- Dick
On 6-Oct-06, at 2:22 PM, Drummond
by an internal account name and not the i-name
synonym they used at the RP -- then we can drop openid.display.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 2:19 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; 'Recordon, David'; specs@openid.net
+1. Josh is right. Ultimately there are three identifiers involved in all
interactions between the User, the RP, and the IdP:
1) User-Presented-Identifier (UPI): the identifier entered by the User at
the RP.
2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by
the RP in
+1 to Kevin's point here -- no second discovery step is needed with an XRI.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kevin Turner
Sent: Friday, October 06, 2006 1:58 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
Let me play the dumb customer here and say:
* A whole lot of real-world users would love OpenID-enabled bookmarks.
* A whole lot of websites would love to offer them.
* A whole lot of IdPs would love to provide them.
Kevin Turner
At David's suggestion, to make it easier to follow, I've posted what I
believe is a consolidated delegate proposal at:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
This incorporates Josh's original, Martin's, Josh's amendment, and my
amendment to Josh's.
Josh and
+1 to one key takeaway from this whole thread: that the
marketing/evangelism/messaging around OpenID MUST be very careful to clearly
communicate, in Gabe's words, what it can and cannot do right now.
Especially when it comes to hard problems like authentication context and
circles of trust that
Brad, thanks much for posting this. Having spent a ton of time on identifier
abstraction -- largely for the benefit of identifier portability -- I have
enormous respect for this feature.
So I am committed to being super-careful we don't break it just by renaming
it.
My proposal was limited to
80 matches
Mail list logo