Re: Are the Discovery Components Done Enough?

[David Fuelling]

On Tue, Jun 9, 2009 at 9:19 PM, SitG Admin
wrote:

> There's a significant camp of people that believe this information should
>> be included in DNS.  There's also a significant group of people who believe
>> it could be located an XRD file (or, "on the web").
>>
>
> What if the discovery document says "E-mail this autoresponder address."?
>
> Should all discovery (in OpenID) be able to take place over the HTTP/HTTPS
> protocol, or will it be flexible enough to accept plugins for extending the
> base discovery method?
>
> -Shade
>

I'm inclined to support the latter -- In some future version of OpenID Auth
(possibly even 2.1), I would love to see a bunch of OpenID Extension specs
that deal only with the topic of Discovery.

In fact, one way to go (and this is admittedly a bit radical) would be to
just define a generic way to do Discovery in the main OpenID Auth 2.1 core
document, and then make _every_ identifier into an extension.  That includes
URL, XRI, email, etc.

Radical, I know, but I like modularity, and it will likely preclude the
debate about why we should or shoud not be able to use email addresses as
OpenID's.  Or why we should/should not use my fingerprint as an OpenID.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[David Fuelling]

Great feedback.  I took the liberty to add this to the "Discussion Points"
on the wiki page.
http://wiki.openid.net/OpenID-Discovery

On Tue, Jun 9, 2009 at 8:43 PM, Allen Tom  wrote:

> My primary concern with changing OpenID Discovery is the upgrade path to
> the new discovery mechanism. It took way too long for everyone to upgrade to
> OpenID 2.0, so I'd like to have a better understanding the upgrade path to
> OpenID 2.1 and/or the new Discovery mechanism.
>
> Allen
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[David Fuelling]

My bad -- I errantly thought you were advocating the opposite.

On Tue, Jun 9, 2009 at 9:15 PM, Breno de Medeiros  wrote:

> And I agree with you. My view is that in the absence of an OpenID discovery
> WG there will be _more_ uncertainty about future directions for the spec,
> not less.
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[David Fuelling]

On Tue, Jun 9, 2009 at 7:09 PM, Breno de Medeiros  wrote:

> If we start the process to form a WG for discovery now, most likely the
> process would only be completed in 6 months, even if there was considerable
> agreement and stable technologies to draw from.
>
> Right now, there is quite a bit of momentum and excitement about
> Webfinger.  The XRI TC is hoping to publish draft specs for XRD withing the
> next 30 days. Concurrently, and in particular after that, it is hoped that
> progress on webfinger will be speedy. Webfinger spec discussion may take
> place at either XRI TC or IETF.
>

Even if webfinger does become its own spec, I'm not confident it will be end
up looking the same in the context of OpenID (there are thorny issues like
Authority to contend with: e.g., what system is the meta-data authority for
an email address?   DNS? Web (Host-meta?)? Both?  Something-else?

I guess my opinion is that this work needs to happen in both places, so why
not start it here as well.

Should we just start responding to all threads about OpenID 2.x discovery by
> saying that the discussion is taking place at some other mailing list?


Last point to reiterate: There are a lot of Discovery issues besides email
addresses and XRD.  See the wiki for more.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[David Fuelling]

On Tue, Jun 9, 2009 at 7:00 PM, Santosh Rajan  wrote:

>
> We need to remember that XRD only addreses discovery for URL identifiers.


This is not really true.  The XRD document schema only demands that an
identifier be a URI, both for the XRD document's "subject" (i.e., the
canonical-id) and the XRD document's "alias" (i.e., other synonymn
Identifiers).

"da...@google.com" is really the following URI: "mailto:da...@google.com";,
and would work just fine in XRD.



> XRD
> does not address email like identifiers. XRD actually has two properties.
> 1) generic format for resource descriptor documents (XRD documents)
> 2) protocol for obtaining XRD documents from HTTP(S) URIs.
> For email identifiers we are using only property (1) which is by and large
> defined, except for the signature part.
>

Actually, XRD relies on a "well known location" to begin the Discovery
process.  That is the subject of a different spec called "Host Meta" (
http://tools.ietf.org/html/draft-nottingham-site-meta-01).  FYI, Eran has a
great blog post on all of this here:
http://www.hueniverse.com/hueniverse/2009/03/the-discovery-protocol-stack.html

All that to say: as long as OpenID defines how to locate the "host-meta"
file for a particular Identifier (like an email address), then that
Identifier can work just fine with XRD, and we can then use that identifier
(e.g., an email address) in the OpenID flow (some other parts of the spec
would need to be adjusted for this to actually work, but you get the idea).

We (the OpenID community) just need to define how this is going to happen
(thus, the 2.1 Discovery WG).
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[David Fuelling]

David,

Great questions -- see my thoughts/opinions inline...

david

On Tue, Jun 9, 2009 at 6:36 PM, David Recordon  wrote:

> Hey David,I've been following some of the discovery work the past few
> months, but don't have a clear picture if the various components are
> actually solid enough to begin working with.
>

This is a valid concern.  From what I can gather from the XRD discussions,
it seems like the last remaining "issue" with XRD is the signature format to
adopt.  Other than that it seems like XRD is very close (XRI TC particpants
correct me if I'm wrong -- I don't speak for the TC as I've mainly been
lurking there).

Granted, it will take time to get community feedback on XRD, and move
through the OASIS standards mechanisms, but it seems like there's enough
meat there to begin drafting a document that would outline how the OpenID
community should utilize XRD (I think that's the expected deliverable from
the Discovery 2.1 WG, anyway).

To me, it seems like the 2.1 Discovery WG _could_ be happening in parallel.
After all, the 2.1 Discovery WG is only producing a "recommendations" doc.
The official 2.1 WG could choose to ignore that doc.


>  I know XRD is moving forward, but what's the state of site-meta (
> http://tools.ietf.org/html/draft-nottingham-site-meta-01)or
>  now WebFinger (
> http://code.google.com/p/webfinger/)?
>  Is there something in WebFinger which wouldn't solve OpenID discovery
> entirely?
>

I'll defer to Eran on the state of site-meta.  I have been participating in
some preliminary (and brief) discussions on the webfinger list (see here:
http://groups.google.com/group/webfinger/browse_thread/thread/7936700f02b0049b).

I tend to agree with Eran about not needing to normatively specify
webfinger.  XRD really takes care of the entire discovery process for email
addresses (we just need the intro part that says "where to look" when
presented with an email-like identifier).  Essentially, webfinger would be a
2 sentence spec:

1.) Look for an "@", split the identifier around the "@", and use the
"domain" portion of the email to get the host-meta file.
2.) Use XRD to perform discovery on the identifier.

I wouldn't be opposed to making a normative spec out of webfinger, but in my
experience with EAUT and the discussions around email as an OpenID, there
were some fundamental disagreements about authorities for email addresses.
There's a significant camp of people that believe this information should be
included in DNS.  There's also a significant group of people who believe it
could be located an XRD file (or, "on the web").  And some (like me) who
believe it could be located in both places, with one taking precendence over
the other, plus clear rules of how to behave if one authority is missing.

All that to say, I think the OpenID community should take the _principles_
of webfinger, and create its own spec to deal with email addresses.  The
notion of getting a normative webfinger spec that satisfies every use case
on the Internet (i.e., a generic webfinger spec) seems a bit unlikely to me
(I could be wrong).

All that to say, I think we in OpenID land should specify how _we_ treat
email-like identifiers in our own normative spec, using the principles of
webfinger.

(whew -- sorry for being so long winded).

;)



> These questions and the lack of adoption of XRD, site-meta or completion of
> WebFinger have all contributed to my belief that we're still just not ready
> to redefine how OpenID's discovery process should work.
>

My opinion is that we know enough to get the ball rolling.  There are a lot
of other outstanding issues relating to discovery than just XRD.  It's a
valid point, though, and I would be open to the counter-arguement that says,
"we should wait till XRD, LRDD, etc are finalized before we consider them".
I guess I'm more of the opinion that the 2.1 Discovery WG is going to
produce a "guidance document" about 2.1 Discovery, and it seems like we know
enough about XRD and its associated protocols to begin discussing and
drafting that document.

I guess an additional, if not bigger, question is:  do we need a 2.1
Discovery WG to produce a "best practices" doc?



>
> Thoughts?
>
> Thanks,
> --David
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID 2.1 Discovery WorkingGroup?

[David Fuelling]

Hey All,

There have been quite a few questions/issues raised concerning the next
iteration of OpenID Discovery.  I have tried (as best as I could) to
document these on the "*OpenID 2.1 Discovery WG*" wiki page (
http://wiki.openid.net/OpenID-Discovery).  Please feel free to add or edit
if you think I have missed or mis-characterized anything.

In my opinion, I'm comfortable with the current scope of the proposed WG --
which is (my words) "to come up with a best-practices/recommendations
document that could/will be utilized in future specs".

Assuming all of the Discussion points on the wiki are valid and make sense,
then I am now of the opinion that we should re-consider the idea of having a
separate "Discovery" WG.  Also, we should re-consider whether this WG should
"do its thing" before we begin the formal work of the Auth 2.1 WG.

I'm really open to doing this any way (combined, separate, sequential, etc),
but it seems like there are enough issues surrounding Discovery that it
might be more focused and easier to deal with if it was part of its own WG.

Thoughts?

David

ps - here are some (mutually exclusive) potential ways to structure this:

A.) Create a "Discovery WG", whose result will be a "best practices"
document that can be used in future OpenID protocol (or otherwise) work.
Then, start the OpenID Auth 2.1 WG.
B.) Create separate "Discovery WG" and "Auth 2.1 WG", both doing their work
at the same time.
C.) Have just a single WG, which addresses both "Discovery" and the "2.1"
protocol.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

[David Fuelling]

+1

On Tue, Jan 27, 2009 at 3:33 PM, Dick Hardt  wrote:

> I'd prefer to narrow the scope of the WG and keep it focussed on a small
> number of goals.
>
> A separate WG on SREG would be preferred, but I think it is a disservice to
> the community to have two specs having such significant overlap.
> Choice in this case leads to confusion and reluctance to invest. The
> challenge is that those with an investment in SREG now have a propensity to
> see it continue on even though intellectually they can see the advantage of
> a unified spec.
>
> fwiw: I am in an off-site most of this week and won't be able to engage
> significantly until next week.
>
> -- Dick
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: New OP-MultiAuth Draft Published

[David Fuelling]

On Sun, Jan 18, 2009 at 10:41 PM, Paul Madsen  wrote:

>  Hi David, your extension is an authentication policy declaration from the
> user to the RP.
>
> PAPE allows the RP to declare its authentication policy to the OP (and vice
> versa).
>
> I wonder if there is an opportunity for convergence?
>

I'm open to anything, although PAPE is more of an Auth extension, whereas
MultiAuth (at least in its present form) is more of a Discovery extension.
If the community sees value in something like this, I think a better place
for it would be inside of OpenID Auth Discovery 2.1.



>
> Or at minimum a naming scheme that hilites the commonality .. UAPE :-)
>

> paul
>
> David Fuelling wrote:
>
> For anyone interested, I've put out a 2nd draft of my OP-MultiAuth idea.  I
> think the first draft was pretty confusing, so hopefully this clarifies
> things a bit more.
>
> Wiki Page: http://wiki.openid.net/OP-MultiAuth
> Actual Draft:
> http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html
>
> In a nutshell, the idea here is to protect end-users against a "rogue OP"
> by providing a mechanism for a Claimed Identifier to mandate that an RP get
> valid auth assertions from two or more different OP's before giving access
> to RP-protected resources.
>
> Thanks!
>
> David
>
> --
>
> ___
> specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs
>
> --
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.552 / Virus Database: 270.10.8/1899 - Release Date: 17/01/2009 
> 5:50 PM
>
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

New OP-MultiAuth Draft Published

[David Fuelling]

For anyone interested, I've put out a 2nd draft of my OP-MultiAuth idea.  I
think the first draft was pretty confusing, so hopefully this clarifies
things a bit more.

Wiki Page: http://wiki.openid.net/OP-MultiAuth
Actual Draft:
http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html

In a nutshell, the idea here is to protect end-users against a "rogue OP" by
providing a mechanism for a Claimed Identifier to mandate that an RP get
valid auth assertions from two or more different OP's before giving access
to RP-protected resources.

Thanks!

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

CLARIFICATION: Is OpenID Discovery Optional?

[David Fuelling]

All,

Wondering if anybody, especially the original OIDF Board and any
contributor's to the OpenID Auth 2.0 spec could comment on this question for
me.

*Is OpenID Discovery, as seen in section 7.3 of the Auth spec, optional?
More specifically, is the information returned by discovery meant to be
Authoritative for a particular OpenID or OP Endpoint, or is it merely meant
to be "Informative".
*
Thanks!

David

ps - for those interested, see the other mail-list thread entitled, "DISCUSSION
relating to OpenID Discovery 2.1" for more fine-grained details surrounding
this question and it's possible answers.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1

[David Fuelling]

On Tue, Dec 30, 2008 at 7:00 PM, Peter Williams wrote:

>  I gave up half way through my careful reply, as it was approaching
> formatting-incomprehensible …to the poor reader trying follow it, point by
> inset counterpoint.
>

Yes, I encountered the same thing in my responses.  :)

>
>
> 1.is metadata mandatory (XRDS or HTML)? Id claim no, by design concept. My
> proffer of proof is an example: the op-initiated unsolicited assertion
> (which has no openid-classical user input stage, and thus no discovery,
> SAML1-like). The nature of AX update is secondary proffer.
>
Correct me if I'm wrong, but in your proffer case, an unsolicited assertion
will still have an OpenID Identifier, correct?  Before accepting such an
assertion, the RP should verify that the OP sending the assertion is the
entity who can actually make that assertion.  To do that, the RP must either
perform 7.3 "discovery" on the claimed identifier (just for validation
purposes), or the RP must validate the Claimed Identifier in some other way
(referencing my previous thread, I would argue this "some other way" must
always have its root in 7.3 Discovery -- though it's really just verfication
in this scenario).

So, the question becomes: How does an RP figure out who can (and who cannot)
make an assertion on behalf of a given Claimed Identifier?

Are you saying that the manner in which this is done is merely "SUGGESTED"
by the spec, but that RP's can pretty much choose to figure this out any old
way they want?  See my response to your #5 below for why this is such a big
deal to me.


>
>
> 2. Even if metadata via openid discovery is mandatory for an act of
> interworking, it's not "intended" (read "conceived") to serve as a control
> framework (for authorization, privileges, permissions, contract bindings,…)
>
> I'm not sure you can separate the two -- If "metadata via OpenId Discovery"
is mandatory, then it becomes an authority over the Claimed Identifier
(regardless of intent).

>
>
> 3. Some folk evidently see a cousin of the openid2 XRI name servers (XDI)
> as the infrastructure in openid's future that is intended to play the role
> (one day) of a fully-fledged, very well-designed authority-based distributed
> control framework -representing the large-N OP->SP trust models, the
> attribute contracts per SP webapp, the EDI-style "interworking agreement",
> the contract arrangements, the legal terms and conditions… However, XDI is
> hardly established practice in OpenID world. I'm not sure if there even
> exists a single production usage! It's obviously R&D. (if anyone can counter
> this, let me know; I WANT to try it out, to see if/when it will be viable
> for business use.) XDI may not never come to be adopted in the "finalized
> specs", if Nat's alternative "CX" regime supplants it (or the highly
> practical internet-based MPLS-VPNs (per Rapattoni) become the norm for
> wire-speed trust networking).
>
>
>
>
>
> 4. you say "To my way of thinking, this should be clarified in OpenID auth
> 2.1 -- at the least, if an RP is going to use some non-7.3 mechanism to get
> an OP Endpoint URL, then that "mechanism" MUST be populated via traditional
> Discovery. "
>
>
>
> Why! ..is it so important to you? This proposition essentially turns
> OpeniD2 into Shib. I might as well just use Shib, and get the assurance of
> properly specified types expressed in a decent type language. OpenId has
> really intellectually done nothing if all it does it replace XML with
> name-value pairs, and SAML metadata with XRDS, and one metadata-based
> control model for protocol orchestration…with another.
>
>
>
Yes, it's very important -- see my response to your #5.


> But at least you are being direct and honest about the desire. The
> "advanced" notions that folks settled on 2 years ago clearly need revisiting
> – to see which work, which got adopted  in practice, which should get
> dumped, and which get another  try as they are obviously still
> works-in-progress.
>
>
>
> 5. I suspect, while focusing on points about
> metadata/authorization/control, we are really tangentially addressing the
> bugbear topic of all websso schemes: repurposing, and the desire of the
> asserting party to  control who can repurpose an assertion (or reuse a AX
> response). And of course, that goes  to the heart of the current social
> debate on who controls a users data, the user or the TTP. Once user's own
> their data, lots of very traditional business models go out of the door.
> Lots of governance models also get left behind. Ensuring that such
> "old-model" controls can be overlaid on such as websso (to control
> downstream actors) has to be expected. So far, the  openid project has not
> been a foil for shib-like infrastructure governance models (though one can
> and should overlay those constructs on OpenID, OPTIONALLY, per trust
> network)
>
>
>
Here's why this is so important to me:

   1. *User Centric Identity
   *Ideally, I want the user to be in control of their identity, inclu

Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1

[David Fuelling]

 HTML Based discovery.


> 7.3.3 has states in which absence of an HTML discovery document is …an
> entirely "legitimate" state. What happens in that state is not defined
> (compounded in the case that there has been no use of XRI/YADIS)
>
> My opinion is that if 7.3.3 has an "absence of HTML discovery" state, you
must still fallback on 7.3, which says there are only 3 states to pick
from.  So, if I can only pick 3 states/paths, and I can't pick HTML-Based
Discovery, and I can't pick XRI/XRDS, and I can't pick URL/Yadis, then there
are *no* other valid states to pick from.

Using that logic, there is no legitimate "fourth state" (that being one
which is not defined).  It is defined out of existence by 7.3.


>
>
> I thus fail to find that XRDS/HTML is intended to be an
> authorization/control framework. If it is supposed to be, its badly
> specified. I suspect from the phrasing, it supposed to be convenient
> metadata.
>
>
>
See above.  I'm very confident that *if* Discovery is to be performed, then
it must be done via one of the three paths in 7.3.

I'm less confident about Discovery not being optional since the wording is
unclear, but I think the intent was for Discovery to be non-optional (keep
in mind that mandated Discovery could still allow an RP use a lookup table,
or some other mechanism, so long as the lookup table is initially populated
via 7.3 Discovery).


>
>
>
>
>
>
>
>
>
>
> *From:* David Fuelling [mailto:sappe...@gmail.com]
> *Sent:* Monday, December 29, 2008 10:12 AM
> *To:* Peter Williams
> *Cc:* gene...@openid.net List
> *Subject:* Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1
>
>
>
> Peter,
>
> Thanks for your input...see my replies inline.
>
> david
>
> On Mon, Dec 29, 2008 at 4:36 PM, Peter Williams 
> wrote:
>
>  The main problem I have is …you are changing the character of XRDS (and
> XRI 2.0 resolution).
>
>  Yes, but I'd be open to accomplishing these ideas without doing so.
>
>
>
>  In 1, you are turning metadata discovery into a authorization/control
> framework. Won't be long before you will want a "#include QXRI" line in the
> XRDS, that imports XRDs from a superior policy authority, and require the
> XRI client resolver to now to "augment" the XRDs with those from the control
> authority. If OpenID needs an policy-based authorization framework, let's
> consider that in its own right (and there is LOTS AND LOTS of previous work
> to draw on). Let's not break the (nicely working) metadata model, tho.
>
>
>
>  Well, it already is an authorization/control framework.  The value of the
> OP endpoint in your XRDS document is what controls what your OP is.
> Proposal #1 merely extends this to say that you need 2 OP's instead of one,
> and possibly only for certain sites.
>
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

DISCUSSION relating to OpenID Discovery 2.1

[David Fuelling]

Not sure if this made it through to everyone due to the mail list
malfunction, so resending just in case.

david

-- Forwarded message --
From: David Fuelling 
Date: Fri, Dec 26, 2008 at 6:58 PM
Subject: DISCUSSION relating to OpenID Discovery 2.1
To: "specs@openid.net" , "gene...@openid.net List" <
gene...@openid.net>


All,

I'd like to propose that the following ideas be considered as discussion
points in the OpenID 2.1 Discovery WG.  I've updated the OpenID 2.1
Discovery WG wiki
page<http://wiki.openid.net/Working_Groups%3AOpenID_Discovery>to
reflect these ideas, and have provided two very rough-draft proposals
(currently formulated as extensions) to juice up the dialog.  The ideas are
summarized below -- I'd be curious to hear any and all feedback.

Thanks!

David


   1. *Enabling two (or more) headed OP authentication*
   The idea here is to allow an end-user to specify two (or more) OP's in
   the  portion of their XRD so that an RP MUST receive auth
   assertions from both OP's before granting access to protected resources.
   See a rough-draft idea proposal here: OP
MultiAuth<http://wiki.openid.net/OP-MultiAuth>.
   XRI Resolution 2.0 seems to currently prohibit this by default per section
   4.3.3: "*If two or more instances of the same element type have identical
   priority attribute values (including the null value), the consuming
   application SHOULD select one of the instances at random. This consuming
   application SHOULD NOT simply choose the first instance that appears in XML
   document order.*"  Thus, in order to indicate to the RP that both
   OP URI's should be used at the same time, an aditional  element is
   used to signify that identical priority URI's should be used together for
   the purposes of OpenID Auth.

   2. *OP Delegation based upon various characteristics of an OpenID
   transaction*
   The idea here is to allow an end-user to delegate authority over a
   particular OpenID Identifier to divergent OpenID Providers (OP's), depending
   on certain characteristics of a Relying Party and/or certain characteristics
   of an OpenID transaction.  For example, an Identifier might specify a
   different authoritative OP depending on the OpenID-related Service being
   employed (e.g., OpenID 2.0, OAuth, or others); the RP Domain (*.
   example.com); or a pre-defined service Class (e.g., one OP for
   single-factor auth, and another OP when two-factor Auth is required).   By
   providing OpenID Identifiers with the ability to specify multiple OP's based
   on particular characteristics of each OpenID transaction, end-users will be
   able to utilize the best OP for any particular OpenID transaction as they
   see fit (i.e., more control in the hands of the user).  See a rough-draft
   here: OP Delegation <http://wiki.openid.net/OP-Delegation>.

   3. *Discovery Extensions*
   The OpenID Discovery specification should define ways for discovery to be
   extended by other services.  For example, the OAuth+OpenID specification may
   want to peform discovery in slighly different ways than regular OpenID Auth
   2.1 does.  Likewise, ideas numbers 1 and 2 above could be implemented as
   extensions to Discovery instead of being included in the main 2.1 Discovery
   specification.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal to form Discovery Working Group

[David Fuelling]

On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura  wrote:

> 2. Separation of OP into Discovery Service and Authentication Service.
>  In the current terminology, OP spans both Discovery Service and
> Authentication Service.
>  We should be explicit about it.
>
>
+1.  I would like to see discovery services separated from OP services too.


>
>
> John Bradley wrote:
> > Breno,
> >
> > I agree.  I recommended separating discovery into a separate doc for
> > 2.1.
> >
> > There didn't seem to be support for the idea at the time,  perhaps
> > circumstances have changed and the idea will be accepted now.
> >
> > Regards
> > John Bradley
> > =jbradley
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

DISCUSSION relating to OpenID Discovery 2.1

[David Fuelling]

All,

I'd like to propose that the following ideas be considered as discussion
points in the OpenID 2.1 Discovery WG.  I've updated the OpenID 2.1
Discovery WG wiki
pageto
reflect these ideas, and have provided two very rough-draft proposals
(currently formulated as extensions) to juice up the dialog.  The ideas are
summarized below -- I'd be curious to hear any and all feedback.

Thanks!

David


   1. *Enabling two (or more) headed OP authentication*
   The idea here is to allow an end-user to specify two (or more) OP's in
   the  portion of their XRD so that an RP MUST receive auth
   assertions from both OP's before granting access to protected resources.
   See a rough-draft idea proposal here: OP
MultiAuth.
   XRI Resolution 2.0 seems to currently prohibit this by default per section
   4.3.3: "*If two or more instances of the same element type have identical
   priority attribute values (including the null value), the consuming
   application SHOULD select one of the instances at random. This consuming
   application SHOULD NOT simply choose the first instance that appears in XML
   document order.*"  Thus, in order to indicate to the RP that both
   OP URI's should be used at the same time, an aditional  element is
   used to signify that identical priority URI's should be used together for
   the purposes of OpenID Auth.

   2. *OP Delegation based upon various characteristics of an OpenID
   transaction*
   The idea here is to allow an end-user to delegate authority over a
   particular OpenID Identifier to divergent OpenID Providers (OP's), depending
   on certain characteristics of a Relying Party and/or certain characteristics
   of an OpenID transaction.  For example, an Identifier might specify a
   different authoritative OP depending on the OpenID-related Service being
   employed (e.g., OpenID 2.0, OAuth, or others); the RP Domain (*.
   example.com); or a pre-defined service Class (e.g., one OP for
   single-factor auth, and another OP when two-factor Auth is required).   By
   providing OpenID Identifiers with the ability to specify multiple OP's based
   on particular characteristics of each OpenID transaction, end-users will be
   able to utilize the best OP for any particular OpenID transaction as they
   see fit (i.e., more control in the hands of the user).  See a rough-draft
   here: OP Delegation .

   3. *Discovery Extensions*
   The OpenID Discovery specification should define ways for discovery to be
   extended by other services.  For example, the OAuth+OpenID specification may
   want to peform discovery in slighly different ways than regular OpenID Auth
   2.1 does.  Likewise, ideas numbers 1 and 2 above could be implemented as
   extensions to Discovery instead of being included in the main 2.1 Discovery
   specification.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Use of Qworum for indirect communication

[David Fuelling]

Cool idea, although I wonder what benefit this would bring to OpenID auth?
Seems like HTTP redirects and form submits work pretty well today.  Would
Qworum enable any sort of new features that aren't possible today because
we're not using XML between RP/OP/User-agent?

Thanks!

david

2008/12/15 Doğa Armangil 

> The OpenID Authentication 2.0 specification states in section 5.2 that
> "There are two methods for indirect communication: HTTP redirects and HTML
> form submission". It is worth noting that a third method might be added to
> this list: Qworum ( http://www.qworum.com/ ).
>
> Qworum is a fairly new technology (a couple of years old) that aims to
> solve precisely the problem of indirect communication between interactive
> web services (such as between Relying Parties and OpenID Providers). Qworum
> mandates that the caller (i.e. RP) and the callee (i.e. OP) communicate
> through XML documents.
>
> Here is one possible authentication scenario involving Qworum:
>
>
> 1. The RP calls the OP by sending the following Qworum message to the user
> agent:
>
> 
> 
>
>   
>   
>
> 
> 
>   checkid_setup
>   http://openid-provider.net/my_id
>   ...
> 
>
>   
>
> 
>
> This message instructs the user agent to call the OP and to send the result
> back to the RP.
>
> 2. The user agent then calls the OP (i.e. http://openid-provider.net/my_id) 
> by POSTing it the following XML document:
>
> 
>   checkid_setup
>   http://openid-provider.net/my_id
>   ...
> 
>
> 3. The OP interacts with the end user.
>
> 4. The OP sends the following Qworum message to the user agent:
>
> 
> 
>   id_res
>   http://openid-provider.net/my_id
>   ...
> 
>
> 5. Finally, the user agent then POSTs the authentication response message
> back to the RP. Note that the RP return address is handled by the user
> agent, not the OP.
>
>
> Adding Qworum as a third communication method would not break existing
> methods, it would just offer one more choice to RPs:
> * The RP can check whether the user agent has Qworum capability by
> inspecting the Accept header of the HTTP request. The RP can then choose to
> use Qworum.
> * The OP would understand that the RP is using Qworum to call it if the
> Content-Type of the HTTP POST request is application/xml.
>
> So my question is this: Has Qworum been considered for indirect
> communication, or could it be considered in the future?  (As the lead
> developer of Qworum, I can affirm that Qworum would do all it can to
> facilitate this process.)
>
> --
> Doğa Armangil
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: non-standard login mechanism

[David Fuelling]

Sounds like you're simply mapping a SL UUID to an OpenID, so my opinion
would be "no, this does not break the spec", so long as the actual OpenID
transaction utilizes the OpenID URL that you have on file in the DB.

This is very similar to the other discussions going on regarding using an
email address in-lieu of a user's OpenID, since in the real world the email
address is the identifier users are arguably most familiar with (currently,
anyway).  Note here that "mapping" to an email address does not break the
spec, but there is talk of ammending the spec to make email addresses actual
OpenID's.

david

On Mon, Nov 17, 2008 at 1:46 AM, SignpostMarv Martin <
[EMAIL PROTECTED]> wrote:

> Just polling for feedback on a bit of a non-standard login mechanism
> I've implemented on my site(s).
>
>
> 1) a user logs into Second Life, and clicks a kiosk to get a nonced URL.
> 2) the user gets a fairly standard OpenID form, submitting their OpenID
> (I'm using the Zend libraries, btw)
> 3) once successfully logged in via OpenID, the endpoint and avatar UUID
> are recorded in a db table
> * after this point, the OpenID url will never be entered again (unless
> the user wishes to change their OpenID, or perhaps for circumstances
> where an additional security/paranoia requirement is desired)
> 4) the user visit a SLOpenID v3-enabled website, entering their Second
> Life avatar name
> 5) the code checks if the name is valid, on file, and if it has an
> OpenID associated
> 6) the code then automagically submits the OpenID that is on file to the
> Zend libs (as opposed to accepting a POST or GET value)
>
>
> Do note that Linden Lab don't (currently) have an OpenID provider, and
> since I retired SLOpenID v2, I don't believe there are any that cater
> solely to Second Life Residents- though there isn't really much point in
> it any more, considering flickr, live journal and blogger all act as
> providers (all of which are used by Second Life Residents to varying
> degrees).
>
>
> The purpose of only using the Second Life name is three-fold:
>
> 1) Residents are familiar with entering their SL name (in either
> first/last format or a single string) in several places throughout
> Linden Lab's presence (viewer, websites)
> 2) To strive for a possible standardisation across SL-centric websites,
> increasing people's awareness of possible phishing attacks (see footnote)
> 3) To strive for a possible learned behaviour of passwordless,
> transparent OpenID logins in Second Life viewers (OpenID is mentioned as
> a possibility for OGP logins)
>
>
> So my question is this: Is using OpenID without the user entering the
> actual OpenID url breaking the spec ?
>
>
> ~ Marv.
>
>
> *phishing footnote
> If there are no passwords entered on a SLOpenID v3-enabled website,
> there is no risk of the maintainer of said site being accused of
> manipulating users so that they can collect the actual Second Life
> passwords. If the SLOpenID v3 method were to become commonplace amongst
> SL-centric websites, otherwise-uninformed users (e.g. those that use
> SL-centric services) would be immediately less trusting of phishing
> sites that specifically target SL users (e.g. OH HAI! U CAN HAS FREE L$
> IF U ENTER UR PASSWORDS! KTHXBAI MUAHAHAHA)
>
>
> p.s. this email has been BCC'd to the OpenID mailing list and LL peeps,
> just in case you're wondering why the text of the email is rather verbose.
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposing an OpenID Authentication 2.1 Working Group

[David Fuelling]

 wording and cleanup wording, add
> > diagrams, and if necessary restructure portions of the specification
> > to increase the overall readability and uniformity of interpretation.
> >   - Apply clear copyright licensing language to the specification in
> > addition to noting that is covered by the OpenID Foundation IPR Policy
> > Non-Assertion Agreements.
> >   - Add a new Appendix containing security guidance for implementers.
> > While not intended to be an exhaustive best practices guide, this
> > would consolidate in one section the most important guidelines for
> > securely implementing OpenID, and would incorporate key lessons
> > learned from public implementations.
> >   - Clarifying XRDS Based Discovery for URLs possibly by migrating to
> > using XRDS-Simple. Note that this requires finalization of XRDS-Simple
> > as well as maintaining compatibility with OpenID Authentication 2.0
> > implementations.
> >   - Clarifying if support of XRI as an identifier type is optional or
> > required by Relying Parties and specifying how to use an XRI to take
> > full advantage of its usability, security, and privacy properties.
> >   - Clarifying whether OPs that support associations over HTTPS are
> > required to also support associations using Diffie-Hellman encryption
> > over HTTPS connections.
> >   - Exploratory work as defined below assuming the Working Group finds
> > it feasible to do so.
> >
> > Exploratory Work:
> > The WG will consider the following topics on an exploratory basis to
> > include in the specification:
> >   - Support for email addresses as OpenID identifiers.  It's been
> > shown that identifiers in the form of [EMAIL PROTECTED] are easier for
> > mainstream users to understand, although there are multiple different
> > ways to implement this functionality. This has come up many times in
> > the past; various technological proposals have been made; and there is
> > at least one concrete shipping prototype (EAUT which was based on work
> > initiated by David Fuelling
> http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.html
> )
> > . This is similar to a proposal made by Brad Fitzpatrick (
> http://brad.livejournal.com/2357444.html
> > ) that should be explored further with regard to viability of email
> > addresses as an identifier type in the OpenID Authentication
> > specification. Note that this option may be dependent on large email
> > providers showing interest in supporting this style of identifier.
> >   - Increasing reuse between OpenID Authentication and OAuth Core.
> > Both OpenID Authentication and OAuth Core share a similar protocol
> > flow with similar HMAC style cryptographic signing.  OAuth uses a
> > slightly different and newer signing mechanism. Changing this in
> > OpenID Authentication would break backwards compatibility, but the WG
> > should explore the difference(s) and consider adding support for
> > OAuth's mechanism alongside the current mechanism for forwards
> > compatability.
> >
> > Anticipated Contributions:
> > Specification text from a variety of contributors to achieve the goals
> > listed in the above scope.
> >
> > Proposed List of Specifications:
> > OpenID Authentication 2.1. Completion expected within the next six
> > months.
> >
> > Anticipated audience or users of the work:
> > Implementers of OpenID Providers and Relying Parties.
> >
> > Language in which the WG will conduct business:
> > English.
> >
> > Method of work:
> > E-mail discussions on the working group mailing list, working group
> > conference calls, and possibly a face-to-face meeting at the Internet
> > Identity Workshop.
> >
> > Basis for determining when the work of the WG is completed:
> > Proposed changes will be evaluated on the basis of whether they
> > increase or decrease consensus within the working group.  The work
> > will be completed once it is apparent that maximal consensus on the
> > draft has been achieved, consistent with the purpose and scope.
> >
> > Proposers:
> >   - Allen Tom, [EMAIL PROTECTED], Yahoo!
> >   - Brad Fitzpatrick, [EMAIL PROTECTED], Google
> >   - Breno de Medeiros, [EMAIL PROTECTED], Google
> >   - Carl Howells, [EMAIL PROTECTED], JanRain
> >   - David Recordon, [EMAIL PROTECTED], Six Apart
> >   - Drummond Reed, [EMAIL PROTECTED], Parity/Cordance/OASIS
> >   - Gabe Wachob, [EMAIL PROTECTED]
> >   - Gary Krall, [EMAIL PROTECTED], VeriSign
> >   - John Bradley, [EMAIL PROTECTED]
> >   - Johnny Bufu, [EMAIL PROTECTED]
> >   - Joseph Smarr, [EMAIL PROTECTED], Plaxo
> >   - Josh Hoyt, [EMAIL PROTECTED], JanRain
> >   - Mart Atkins, [EMAIL PROTECTED], Six Apart
> >   - Max Engel, [EMAIL PROTECTED], MySpace
> >   - Scott Kveton, [EMAIL PROTECTED], Vidoop
> >
> > Initial Editors:
> >   - David Recordon, [EMAIL PROTECTED], Six Apart
> >   - John Bradley, [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] OpenID Extension to handle Emails Addresses?

[David Fuelling]

On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins <[EMAIL PROTECTED]>wrote:

> David Fuelling wrote:
>
>>
>> I would even entertain the notion of the OpenID extension doing DNS lookup
>> first, then EAUT, though I need to think more on the topic.  Alternatively,
>> maybe we make DNS optional.
>>
>>
> At this point I'll throw in my more recent post about why DNS must be
> supported and must be the primary mode, with others as fallback:
>
> http://www.apparently.me.uk/18285.html
>
>
Very interesting points in your blog post!!  It has me wondering the
following questions:


   1. The arguments about using DNS could apply to OpenID in general.
   However, OpenID doesn't do anything with DNS.  Why is this?  What were the
   compelling reasons to not use DNS with OpenID?  Is there an FAQ page
   somewhere about that?  I have only vague recollections on the topic.
   2. Do some of the larger email providers have an opinion on the mechanism
   used for "Discovery" in the email case?  For instance, would
   Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based
   discovery be consulted first?  Do they even care?



> However, I wouldn't necessarily object to putting the *EAUT* information
>  in the DNS rather than the OpenID information directly. The two things I
> care most about at this point are:
>
>  * DNS must be consulted first, for the reasons I go into in that post.
>  * In the case where an email address is the claimed_identifier, the OpenID
> request must have openid.identity set to mailto:theemailaddress, not the
> mapped HTTP identifer. (In other words, this is an extension to OpenID
> *Discovery*; the rest of the protocol is unchanged.)


What if the user actually wants their URL to be the claimed identifier?
Would you be open to that?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID Extension to handle Emails Addresses?

[David Fuelling]

Wondering if it makes sense to talk about an OpenID Extension to handle
email address, as opposed to changing the core spec?

My thinking here is that EAUT could be used to solve much of this problem,
but that an OpenID extension is required to add extra value.  So, here's how
I would see such an extension working.

   1. User presents an email-address at an RP.
   2. EAUT is used to transform the email address into a URL.
   3. If EAUT succeeds, then use that URL as an OpenID (possibly doing
   Directed Identity, possibly not).
   4. If EAUT fails, then fail.

That's where EAUT ends.  However, in the OpenID world, I could see striking
#4, and adding one or more of the following:

   1. If EAUT fails, then attempt directed identity on the
http://domain.tldof the email address.
   2. If that fails, look in the DNS for more hints per Martin's
   proposals[1]

I would even entertain the notion of the OpenID extension doing DNS lookup
first, then EAUT, though I need to think more on the topic.  Alternatively,
maybe we make DNS optional.

Is this line of thinking (discussing an OpenID Extension to handle email
addresses) premature?

David

[1] http://www.apparently.me.uk/18285.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Trusted Authentication Extension

[David Fuelling]

John,

Have a look at OAuth (http://groups.google.com/group/oauth).  I think it's
currently a private google group, but it seems like you've given a lot of
thought to this type of thing, so I'm sure the group owners would welcome
your input.  There's a lot of activity going on over there.

David

On 8/26/07, John Ehn <[EMAIL PROTECTED]> wrote:
>
> I have created a draft of a new specification that I think will help to
> fill a gap in OpenID functionality.
>
> What appears to be a newer productivity feature of many websites is the
> ability to import and utilize information from other sites.  For instance,
> Basecamp provides an API that allows other systems to access user data.
> This is a great feature, but it currently cannot be done with OpenID, due to
> the dependence on end-user interaction during the authentication process.
>
> The Trusted Authentication Extension provides for the ability for an
> OpenID Consumer to log in to another OpenID Consumer without user
> interaction.  The end user will be able to create a trusted connection
> between two OpenID enabled sites, which will allow a client site to access a
> destination site using the end user's Identity.
>
> Please provide your comments and feedback, as they are most appreciated.
>
> http://extremeswank.com/openid_trusted_auth.html
>
> Thank you,
>
> John Ehn
> [EMAIL PROTECTED]
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenId as API authentication method

[David Fuelling]

What is OAuth?  The group appears to be private, so is not accessible.

david

On 7/27/07, John Panzer <[EMAIL PROTECTED]> wrote:
>
>  You should probably check out OAuth:
> http://groups.google.com/group/oauth, and its draft 
> spec.
>
>
> Eran Hammer-Lahav wrote:
>
>  I am not sure if this belongs in the spec list, but I'll give it a try.
>
>
>
> I would like to suggest adding some text to section 11.1 (or anywhere else
> that's appropriate) that will provide guidelines for using OpenID in a
> scenario where the OpenID RP is not the site the user is actually using. The
> OpenID specification is written with some bias towards implementation in a
> website environment which is the most common use. My aim is to use OpenID as
> the authentication method for establishing API sessions. I am building a web
> service where the client (any user of the API) requests to create a session
> token which can then be used to bypass authentication for a certain period
> of time (nothing new here).
>
>




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

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

[David Fuelling]

On 6/11/07, Josh Hoyt <[EMAIL PROTECTED]> wrote:


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 work, this is not the case. The canonical
identifier is the sole database key, and the URL that the user enters
and everyone sees is reassignable and (to a certain extent) ephemeral.
Control of the canonical identifier is necessary and sufficient to
assert one's identity.



Yes, I think that's what is intended.  However, there doesn't appear to be
any mechanism (aside from the proposal "saying so") to enforce that the
canonical identifier is the root key.  Seems like somebody could arbitrarily
switch their canonical id to a different canonical id, so long as the person
doing the switching controls a regular OpenID and its XRDS file that
specifies the canonical id.  Am I missing something there?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[David Fuelling]

Assuming I understand things correctly, it seems like what we're calling a
canonical URL in this thread is really a pseudo-canonical URL since a given
OpenID's XRDS doc is what specifies the Canonical ID.

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 so, then It seems like there's almost a (in a good way) circular
reference going on, since at certain points in time, what we're calling the
"Canonical URL" is the unchanging/stable/authoritative URL, while at other
times, the actual OpenID is the authoritative/unchanging/stable URL.

In this setup, I a given person has to control 2 URL's at the same time in
order to assert ownership of a given OpenID, making it difficult to lose
your Identity if you lose only a single domain.  In this respect, each URL
provides a safeguard against the loss of the other URL.


On 6/8/07, Dick Hardt <[EMAIL PROTECTED]> wrote:


You are still trusting one registry. Of course it is your choice, but
you have a single point of failure. Do you think they will still be
around in 50 years?

On 8-Jun-07, at 4:20 PM, Recordon, David wrote:

> I don't see how it requires a centralized registry, if I choose to
> trust
> that LiveJournal, or some ugly URL from AOL, etc will never go away
> then
> that is my choice.
>
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dick Hardt
> Sent: Friday, June 08, 2007 4:08 PM
> To: Drummond Reed
> Cc: specs@openid.net
> Subject: Re: Do We Agree on the Problem We're Trying to Solve?
>
>
> On 8-Jun-07, at 4:00 PM, Drummond Reed wrote:
>
>>
 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:
>>>
>>> The persistent URL or XRI *is* a master directory. What do you do
>>> when the persistent identifier is compromised, goes out of
>>> business ...
>>>
>>> That is problem B.
>>>
>>> Canonical IDs do not solve B.
>>
>> I completely agree that B is a hard problem. However Canonical IDs
>> solve B
>> if the identifier authority for the Canonical ID follows business and
>> operational practices intended to solve B.
>
> And I think there is a solution that does not require a single,
> central registry.
>
> One of the other issues with the registry is it is challenging to
> provide directed identities.
>
> -- Dick
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

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

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

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

[David Fuelling]

Wrt to the problems we're trying to solve, I think that we should define a
(C) (which is similar to (A), yet instigated by the user and doesn't trigger
an RP recycle) and a (D).

In summary:

A) Identifier recycling normally in large user-base deployments.   i.e.
 needs a way to give 'TheBestUsernameEver' to a new
user if it has not been used in some period of time.

B) Losing control of your own domain name whether that be via someone
stealing it or just that you don't want to have to pay for it forever.

C) If I change my OP (i.e., I start using an OpenId with a different URL), I
should still be able to use all of my existing RP accounts with my new OP,
and prevent my old OP from making assertions for me moving forward.

D) Publicly displayed OpenID's should be distinguishable from one owner to
the next.

IMHO, Canonical ID's seem to solve (A), (B - to some degree - the canonical
URL might get lost, but this could be mitigated), and (C), whereas Fragments
solve (A) and (D), so why not use both?  Plus, (B) can be solved via AX
using private tokens that only an OP, the User, and an RP know (see my
previous post, but make the tokens private).

Side Note: Can't an OP use canonical URL ID's today without adjusting the
current 2.0 spec?  It seems like the proposal is just a Yadis adjustment.

David

On 6/8/07, Recordon, David <[EMAIL PROTECTED]> wrote:


I'm not sure if we all think we're trying to solve the same problem.
The two problems that have been discussed are:
A) Identifier recycling normally in large user-base deployments.  i.e.
 needs a way to give 'TheBestUsernameEver' to a new
user if it has not been used in some period of time.
B) Losing control of your own domain name whether that be via someone
stealing it or just that you don't want to have to pay for it forever.

Have we made a decision as to if we're looking for a solution to solve
both of these problems, only A, or only B?

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

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

Re: Questions about IIW Identifier Recycling Table

[David Fuelling]

Hey Josh,

Thanks for your message and great points.  See my thoughts/questions inline.

On 6/7/07, Josh Hoyt < [EMAIL PROTECTED]> wrote:


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 seem to garner the most checks, per the IIW
grid.  Not
> sure if my idea is technically correct or not, so please let me know if
what
> I'm proposing falls short anywhere.  Here goes

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 that table. Am I missing something?



Maybe I don't understand the difference between private and public tokens.
My proposal used private information to create a public token that can be
sent via AX (thus the hybrid term).  Am I understanding the difference
between private/public tokens incorrectly?

This approach was rejected at IIW because:


1. An extra database field is required (whether or not the data is
transmitted using attribute exchange)



If the AX database schema is architected properly, then the addition of a
new AX attribute should not necessitate a new database column.  If this were
the case, then AX would not really be feasible (how would an RP deal with a
new AX attribute?).


2. There is no obvious way to tell if a user is the same user across

sites (The identifier contains a secret portion)



Good point.  Although, let's assume that RP's display fragment-enabled
OpenID's in the following manner, which overcomes the "Fragments are Ugly"
problem:
http://me.example.com#1234";>http://me.example.com

Users will not be able to easily distinguish that the OpenID is owned by a
different user without hovering over the URL in their browser.  That said,
computers will be able to, since the actual HREF is what counts, I assume.
Has this been discussed wrt to fragments.

3. Concern about depending on a secret for a user to be able to sign

in to a site (David's Wordpress issue)



I think DR had a problem with anything that could be lost, thereby
preventing access to an RP.  Both Fragments and Tokens seem to suffer from
this problem, since in the Fragment scheme, if I or my OP forgets what my
fragment was, I won't be able to login to an RP without recycling my account
(or forcing an account recovery procedure).

Seems like the odds of my OP losing my fragment information are pretty
slim.  Identically, the odds of my OP losing my recycling_password are
pretty slim, too.  What's more, If *I* lose my recycling password, why
should I care?  Only the OP needs to deal with it, and perhaps the OP can
just show me that password in an account settings page when I login(?)


I'm not sure which of these issues were the basis for rejecting this

approach. To me, the biggest problem with it is (2)



I agree that #2 is a problem with the token approach.  However, the fragment
approach doesn't solve the problem of a new OP domain owner being able to
make auth assertions for OpenID's that were created for a previous owner
(See my proposal #3).  This seems to be an edge case, but its effects are
much more devastating than people not being able to visually (or otherwise)
determine who owns a given OpenID.

Maybe the solution is use both approaches at the same time?


Josh


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

Re: Questions about IIW Identifier Recycling Table

[David Fuelling]

Hey Johnny,

Thanks for your clarifications and answers to my questions about [1].

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 seem to garner the most checks, per the IIW grid.  Not
sure if my idea is technically correct or not, so please let me know if what
I'm proposing falls short anywhere.  Here goes

To make Identifier Recycling Happen:
1.) The OP should send the RP a Unique hash value as an attribute in
AttributeExchange.  This unique value should be the hash of :

+ nonce
+ op_secret_password
+ user_supplied_secret_password
+ rp_url.

For example, SHA256["1393k3k3939k" + "op_recycling_password" +
"my_recycling_password" + " http://example.com"; ].

In this scheme, each RP will receive (via Attribute Exchange) a one-way
hashed value that is unique to the OP/RP/OpenId/User combination.  This
value cannot be forged so long as the recycling passwords for the OP and
User are not compromised.  (Note that the user's recycling password should
probably be different from the actual login password).

2.) When an account should be recycled, the OP should force the new user to
supply a new recycling password, which will change the hash received by a
given RP.  This is the signal to the RP to use a different/new account on
the RP side, despite having seen the OpenId before.

3.) This scheme would also protect against an OP domain expiring, and
getting picked up by a malicious new owner.  In this case, the OP recycling
password will not be known/valid, and the the new domain owner won't be able
to make auth assertions for existing RP accounts that were served by the
previous OP owner.

4.) To protect legitimate users from lost recycling passwords, an account
recovery mechanism will need to be in place at a given RP, so that if the RP
thinks the account should be recycled, the end-user has a way to prevent
this (perhaps via email, SMS message, or some other mechanism).  This is a
problem anyway with  the other approaches.

In the end, this approach seems to receive a "Check" under all of the
headers on the IIW grid

Does not require change to delegation == Check
Lost Domain when owning OP == Check
Active Recycling == Check
Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?)
One identifier / New DB Field == Check (all data is stored in the AX
mechanism).
No Strip Fragment == Check
Fragments Can be used by other mechanisms (FOAF, etc) == Check

[1] http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling
[2] http://openid.net/pipermail/specs/2007-May/001767.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Questions about IIW Identifier Recycling Table

[David Fuelling]

I wasn't at IIW, so please bear with me.

In reference to the wiki at
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody
clarify what some of the terminology means?  Specific questions are below.

1.) For URL+Fragment, what is the distinction between "private" and
"public"?

2.) Ditto For URL+Token (I assume this means a public vs. private token?)

3.) What does "DE" mean in the "Does not require change to DE"?

4.) In the "Stolen OP account" header, it appears that all 4 of the proposed
methods have problems.  However do we really want an identifier to be
recycled if an account is stolen ( i.e., what if an account is only stolen
for a brief period, but then recovered?)

4.) What is "Active Recycling"?

5.) In the "New DB Field" header, doesn't an OP/RP need a new DB field in
the fragment scheme, in order to distinguish between the id and the current
fragment?  Or does the OP/RP simply store the whole URL (fragment included)
and parse as necessary?

6a.) What is "MO" in "MO Strip Fragment"?

6b.) What does the "MO Strip Fragment" header mean in general?



Thanks!

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

What Should an OpenId Be? [WAS: RE: Proposal for Modularizing Auth 2.0 Discovery]

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Gabe Wachob
> Sent: Wednesday, February 28, 2007 3:02 PM
> To: 'Drummond Reed'; 'Martin Atkins'; specs@openid.net
> Subject: Proposal for Modularizing Auth 2.0 Discovery
>

> 
> Basically, the Discovery Spec would specify that for any identifier scheme
> to work with OpenID, it MUST define a way of being constructed into an
> HTTP
> URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there
> are other ways of resolving it, then implementations MAY use those other
> methods of resolution ("native resolution", if you will). In essence, this
> is a requirement for HTTP gateway(s) to whatever resolution infrastructure
> exists today.

+1.  

Wherever we go from here, we need to be clear and define exactly what *is*
and what *is not* an Open Id Identifier.  

A while back there was some talk about
whether email addresses should be used as 1st-Class or 2nd-Class OpenIds
(see the wiki here
http://openid.net/wiki/index.php/Debating_Emails_as_1st-Class_or_2nd-Class_C
itizens).  I think it is important to be clear that it is *not* a great idea
to use certain "other" identifiers (email address, phone number, etc) *as*
OpenIds.  Rather, these should instead map to OpenId Http URL's (or XRI's if
possible).

This is important because profile attributes like email address, telephone
number, etc may or may not be private in certain circumstances. 

For example, logging-in with my email address at an RP, which maps my email
address to a publicly-displayable OpenId, is an ok thing to do assuming I
trust the RP with my email address (The RP will hopefully respect my privacy
by displaying my mapped OpenId URL or XRI on publicly facing pages where
appropriate).  

If we drift into the territory that says "emails addresses (or other profile
attributes) *are* OpenIds", then RP's and end-users will run into lots of
problems -- E.g., an RP has a publicly facing page that needs to show a
user's identifier, but doing so with an email OpenId would be bad for the
end user, so the RP is stuck.  

Bottom Line (repeating myself): We need to be clear and define exactly what
*is* and what *is not* an Open Id Identifier.  I think the current spec is
right on the money here:  OpenId Identifiers should be an Http URI or an
XRI.



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

OpenId & Yadis Question

[David Fuelling]

I'm wondering if the following is a correct interpretation of how OpenId 2.0
uses Yadis.  Any clarifications are appreciated.

1.) User navigates to an RP, and enters a Claimed Identifier (e.g.,
http://sappenin.gmail.com).

2.) A Yadis doc is returned as follows:


http://specs.openid.net/auth/2.0/server
https://sappenin.com/ 



Specifically:

A.) Is this the proper way to do delegation?  Above, gmail.com is delegating
to sappenin.com.

B.) If a client gets the Yadis doc above (after navigating to gmail.com),
MUST they (or SHOULD they) navigate to sappenin.com and try to perform
discovery again?  If so, how many delegates are allowed?  Not specified?

Thanks!

David 

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

RE: [OpenID] Wiki page: Attempting to document the "Email Address as OpenId" debate.

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Claus Färber
>>
>> http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds
> 
> I'd prefer to call them [EMAIL PROTECTED] OpenIDs. The concept of using this
> format is not only used for email but also for other types of
> identifiers such as RADIUS zones or Kerberos realms.
> 
> For example, [EMAIL PROTECTED] could be a RADIUS login, a Kerberos
> principal and a Yadis ID/OpenID but not an email address.
> 

HmmmI'm not sure about this one.  I intentionally rooted my definition
of "Email Address" in RFC2822, which is where it should be rooted (if we're
going to call them 'email addresses').  Seems like anything in the form 
'[EMAIL PROTECTED]' would also have an identical root (RFC2822).

Is that not the case for Kerberos realms and RADIUS zones?  In other words,
are these *not* also email addresses? 

david

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

RE: [OpenID] FW: PROPOSAL: An Extension to transform an EMail Addressto an OpenId URL

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Eric Norman
> 
> The other vital property of URL based schemes in addition to
> resolvability
> is that "ownership" can be confirmed.  Email addresses are indeed
> resolvable in the sense detailed here.  Furthermore, ownership can also
> be
> confirmed at some level of assurance by the often used technique of
> sending
> something to the alleged email address and seeing if it can be read.
> 
> However, I think a significant factor is whether this can be done
> quickly
> enough and with few enough tasks for the user such that it's acceptable
> as
> a login process.  Isn't that the real reason for the first/second class
> citizen distinction?

Proof of email address ownership is another interesting "fallout" of my
Email mapping proposal.  For example, we know that example.com controls the
email address "[EMAIL PROTECTED]" since the domains are the same.  If that
email address easily resolves to a URL in the example.com domain (e.g.,
http://beth.example.com) via Yadis and some transform procedure, then this
in itself is enough to prove that the person who controls that OpenId URL
http://beth.example.com also controls the email address [EMAIL PROTECTED] (or
else, somebody mis-configured something at example.com).  ;)

Now, imagine that [EMAIL PROTECTED] resolves to (via the Yadis document at
example.com) the URL http://somethingelse.myopenid.com .  Now, simply by
traversing the email-to-Yadis-to-URL path, we can actually verify that a
given email address is owned by a given OpenId.

This could theoretically work the other way, too.  Imagine somebody logging
into an RP with the following OpenId: http://beth.exampleidp.com.  Using
Attribute Exchange, beth instructs her OP to release her email
([EMAIL PROTECTED]).  The RP can then perform an email transform to validate
that [EMAIL PROTECTED] actually maps to the OpenId Url that she provides.  If
it doesn't, then maybe the RP falls back on "click this link in an email" to
verify that the beth who controls that OpenId actually controls that email.

Once we have a mechanism to map an email to an OpenId, some very cool
verifications are enabled which are ostensibly much more secure than
traditional "we just sent you an email that you need to confirm", which is
not the most secure way to verify an email address.

I still don't know if this is grounds enough to promote email addresses to
first class OpenId citizens, but it's a cool consequence nonetheless.

David

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

RE: [OpenID] FW: PROPOSAL: An Extension to transform an EMail Address to an OpenId URL

[David Fuelling]

> -Original Message-
> From: Robert Yates [mailto:[EMAIL PROTECTED]
>
> 2) Why map the e-mail address to an openid url, which then has to be
> further resolved to a Yadis document?  Why not, instead, map straight
> to a yadis doc and make e-mails full fledged openids.  An openid is
> nothing more than a URI that can be resolved to a Yadis doc.
> mailto:[EMAIL PROTECTED] is a perfectly valid URI and you have
> demonstrated a pretty simple way to map it to a yadis doc.

This is definitely worth considering.  As you know, the extension I have
proposed is highly controversial.  Past objections (i.e., arguments in favor
of *not* using an email in lieu of an OpenId) are numerous -- see my wiki
compilation for more details there [1].

To be fair, some of these objections are quite valid, which is why I decided
to propose a "mapping" from Email Address to URL, as opposed to making Email
Addresses a first class citizen of OpenId.

Chief among these is that it would be nice if this extension could be used
in systems outside of OpenId.  Mainly, Yadis is required to map an email
address to a URL per my extension.

In addition, URL-centric identity is something that I consider to be very
cool and very important -- it's a key piece of Identity 2.0, and not
something I want to abandon.  Thus, I decided to create a "mapping"
proposal, rather than simply something that says, "Openid should embrace
email addresses." 

THIS is because (If I understand things correctly) email-addresses can be
normalized to URI's (mailto:[EMAIL PROTECTED]) in a standard fashion, but
that's not the same thing as a URL (URL's are URI's, but not vice-versa).

Thus, without some kind of mapping to URL, it would probably be unwise to
utilize email addresses as OpenIds.

All that said, you are correct that my mapping proposal does present a way
to get a URL from an email address, so maybe I am just adding an
(unnecessary) extra Yadis call into the mix.  However, I still think that an
extension which makes Email Addresses into OpenId Identifiers would *feel*
different from the extension I proposed, which simply maps an email to a
valid OpenId URL.

It's a subtle difference, and one that I think has often been misunderstood
on the mailing lists.  One is a mapping, which says "you can use an email
address at an RP".  The other, which just doesn't feel right to me, says
that an email *IS* your Identity Identifier, which is tough to swallow.

In reality, I'm not sure if this is just something I *feel*, or if there is
a legitimate technical difference between the two.  I think that they are
technically the same, but the latter notion implies something
philosophically about Identity 2.0 that perhaps should not be implied.

I'd appreciate more feedback from the community on this point before I could
endorse making Emails first-class OpenId citizens (although my proposal
essentially does this via "mapping" sleight of hand).

What do you think?

Thanks!

David

[1] http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds

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

Wiki page: Attempting to document the "Email Address as OpenId" debate.

[David Fuelling]

Hi List,

In light of my recent extension proposal to map Email Addresses to OpenId
URLs, I have setup a wiki page on openid.net that attempts to capture all
the pro/cons/issues that have been shared in the debate over whether this is
a good idea or not.

http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds

I have tried as best I can to present a "non-partisan" wiki page that simply
details the pros/cons of each argument.  Basically, the point is to document
all sides of the debate, and *not* to endorse one side or the other.

That said, I'm sure some of my bias is present in the initial wording, so
please feel free to suggest changes to my wording, or make them yourself. 

In addition, please add additional arguments and rebuttals as you see fit.
The page is not nearly exhaustive (I plan to add some "arguments in favor" +
rebuttals tomorrow when I have time).

Thanks!

David

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

Yadis/XRDS Service Element URI Question

[David Fuelling]

Hey All,

I'm working on a draft OpenId 2.0 extension [1] and am looking for guidance
on how to define a Yadis Service Element that includes a URI Template
(instead of a real URI).

At first, I thought that the following would be ok:


  http://openid.net/srv/oeat/1.0/ett
  https://{username}.example.com/


However, 'https://{username}.example.com/' is not a valid URI, since the '{'
and '}' characters are reserved per the URI specification.

So, should I simply "percent encode" the URI above to be
'https://%7Busername%7D.example.com/', or should I define a new Service
Element child, like the following:


  http://openid.net/srv/oeat/1.0/ett
  https://{username}.example.com/


Does Yadis/XRDS require the presence of a URI child in a service element?
Is it legal to define new children elements?  Is that advisable?

Thanks!

David

[1]
http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.
html

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

RE: [OpenID] FW: PROPOSAL: An Extension to transform an EMail Address to an OpenId URL

[David Fuelling]

> -Original Message-
> From: Robert Yates [mailto:[EMAIL PROTECTED]
> 
> For what it's worth I think that this is excellent. 

Thanks for the positive feedback!  

>A couple of suggestions:
> 1) You probably should take a look at the URI Template spec [1].
> These guys have done a lot of the work for you. The spec is still in
> active development and has been blogged about by the author [2], I
> think that they are about to release a new version with some updates.
>

>
> [1]http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-00.txt
> [2]http://bitworking.org/news/URI_Templates

Thanks for the pointer.  After briefly perusing the URI Template spec, it
seems to be a perfect replacement for what I defined in the Email Transform
(ET) extension (I used a '[' and they used a '}', but the idea is the same).


To keep things simple (the ET extension only defines a single replacement
value at present), it seems like rather than including another
specification, I should just edit the ET spec to conform to the URITemplate
proposal.  Of course, I'm always open to other ideas/thoughts.

David 

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

HTML-based discovery Question...

[David Fuelling]

Can anyone give me a brief overview of why HTML-Based Discovery is only
allowed for Claimed Identifiers?

I don't disagree with the spec here -- I'm just trying to understand things
better.

Thanks!

David

(Section 7.3.3): "HTML-Based discovery is only usable for discovery of
Claimed Identifiers. OP Identifiers must be XRIs or URLs that support XRDS
discovery."

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

RE: Proposal: SMTP service extension for Yadis discovery

[David Fuelling]

> -Original Message-
> From: Dmitry Shechtman [mailto:[EMAIL PROTECTED]
> Subject: RE: Proposal: SMTP service extension for Yadis discovery
> 
> > there's nothing wrong with transforming an email to
> > an OpenId Endpoint url (using the root domain of the email).
> 
> That would require a rule for such a transform. Should it be
> http://example.com/[EMAIL PROTECTED] Or maybe http://example.com/~bob? So
> an explicit resolution protocol is required. Why not deploy a plain SMTP
> extension?

Three benefits to using Yadis (and OpenId extensions):

1.) We don't have to mess with MTA stuff (read: It's easier to do, better
for adoption, etc).
2.) OP's will already be deploying YADIS (or HTML-based rel links, which
could be used instead).
3.) Every site can have its own transform rule, since the transform rule can
be defined in the Yadis service doc.

On that last point, maybe our OpenId extension works as follows:

1.) Given an email ([EMAIL PROTECTED]), take the domain of the email and treat
it as an OpenId Endpoint URL (http://example.com).  
2.) Perform OpenId discovery on this URL to get a Yadis service document.
3.) Look for a service type specified by the emailToOpenId transform
extension (maybe http://ext.openid.net/emailTransform or something better).
4.) If the service exists in the Yadis doc, then investigate its URI element
for some sort of replacement pointer (like ['username']) and use that
pointer to perform the transform.
 
So, for example.com, the Yadis service document might include the following
service:



http://ext.openid.net/emailTransform
http://example.org/[username]


Using the rule above, with the wildcard/replacement indicator specified by
our extension ('[username]'), we have an OpenId of 'http://example.com/bob'.

4b.) If the Service was defined as follows:



http://ext.openid.net/emailTransform
http://example.org/~[username]


then the email address would map to 'http://example.com/~bob', and so forth.

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

RE: [OpenID] Questions about Spoofing OpenId

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Carl Howells
> Subject: Re: [OpenID] Questions about Spoofing OpenId
> 
> Some care has to be
> taken to make sure that direct cross-linking won't work, but that's not
> too difficult.

What do you mean by "direct cross-linking"?



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

RE: [OpenID] "The Case for OpenID" published by ZDNet / DigitalIdentity World Blog

[David Fuelling]

Looks like the article got Slashdottedthere's some interesting
commentary going on, with some FUD, plenty of confusion, and some
acceptance.  Very interesting to read.

http://it.slashdot.org/article.pl?sid=06/12/05/139204


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Johannes Ernst
> Sent: Monday, December 04, 2006 6:36 PM
> To: general
> Subject: [OpenID] "The Case for OpenID" published by ZDNet /
> DigitalIdentity World Blog
> 
> David Recordon and I co-authored an op-ed article
> 
>  "The Case for OpenID"http://blogs.zdnet.com/digitalID/?p=78
> 
> that was just published by ZDNet / Digital Identity World Blog.
> If you like it -- or if you just want to raise OpenID awareness, feel
> free to digg / magnolia / ... it ;-)
> 
> 
> P.S. If you are at IIW this week, please stop by and say hi.
> 
> Cheers,
> 
> 
> 
> Johannes.
> 
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/general

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

RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers)

[David Fuelling]

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 10, 2006 11:28 AM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL]
> Handle"http://[EMAIL PROTECTED]" Style Identifiers)
> 
> I strongly have the view that [EMAIL PROTECTED] is a really bad idea.
> 
> Your dad is not providing his password to the RP, and should not be
> prompted for his username there.
> 
> He should be prompted for the site he wants to get sent to where he
> can then enter his credentials.
> 
> This model is something your dad is likely even more familiar with,
> typing in hostname into the address bar. Typing in the site where he
> logs in is what he does at the OpenID prompt.
> 
> btw: why is this thread cross posted?
> 
> -- Dick

Dick, 

Valid points.  I'm curious to know: 

1.) Do you think 'email address normalizing to IdP URL [ignore userid]'
would qualify as an OpenId extension (i.e., could it "ride on top" of the
current protocol)?

2.) Would you have the same objections if this were an extension, but not in
the formal spec? 


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

RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers)

[David Fuelling]

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 10, 2006 11:28 AM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL]
> Handle"http://[EMAIL PROTECTED]" Style Identifiers)
> 
> btw: why is this thread cross posted?

Sorry, I think the original post (or some of the replies) was/were posted to
specs and General, so I was just following that lead.  I guess by this point
most subscribers have subscribed to all the appropriate lists, so this
probably belongs on the specs list.

David

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

RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers)

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf
> Of Jonathan Daugherty
> # I think that all this discussion about email userid is moving us off
> # track.  My original proposal was that the email maps/normalizes to a
> # URL of an IdP (the userid is ignored/not used).
> #
> # So, '[EMAIL PROTECTED]' would be treated as if the User had entered
> # 'http://any.edu' (the URL of their IdP/OP) into the OpenId login
> # form.
>
> Then why not just enter 'http://any.edu' or 'any.edu' instead?
>
> --
>   Jonathan Daugherty
>   JanRain, Inc.

True, there's almost no difference on the OpenId side.  On the human side,
email is more familiar to a typical user (e.g., my Dad) who may not know
to try and strip off the "dad@" part of his email to use with OpenId.

Plus, why do we **not** want OpenId to work with email addresses (assuming
we maintain the principals of User Centric Identity if we use them?)


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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Friday, November 10, 2006 2:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers
>
> I provide email addresses to some of my friends, but I don't provide
> them with corresponding OpenID identities. By an unfortunate twist of
> fate, the domain I provide these addresses in is also my website, and
> since my site doesn't require authentication the WWW-Authenticate header
> is ignored. Consequently, http://[EMAIL PROTECTED]/ will end up
> at *my* website, not the website of the person who uses
> [EMAIL PROTECTED]
>

Ok, so (just to clarify) in your example we're talking about an email
address '[EMAIL PROTECTED]' that maps to a url at an IdP, such that
the mapped URL includes the username ('http://[EMAIL PROTECTED]')
[** just to be clear, this is David R's proposal...my proposal ignores the
userid in the email address **]

So, in your example, if you have given someone an email address with a
domain 'mydomain.com', and you choose not to offer OpenId services, then
emails in your domain can't be used with OpenId.  I don't see the problem,
-- you own the domain, after all, and should control that decision.

Additionally, your scenario is also true in the case of a regular Identity
URL that you give out.  If you provide an Identity URL
'http://someuser.mydomain.com', but you happen to support some other User
Centric Identity standard (i.e., not OpenId), and your user tries to use
the URL that you provided (with an OpenId RP), he'd get the same result.


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

Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

[David Fuelling]

Hey David,

Thanks for your ideas.  Some more thoughts below.

> -Original Message-
> From: David Nicol [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 09, 2006 6:49 PM
> To: David Fuelling
> Cc: Martin Atkins; specs@openid.net; [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> On 11/9/06, David Nicol <[EMAIL PROTECTED]> wrote:
>  
> http://[EMAIL PROTECTED] (cool addy, btw) certainly
> won't get anyone to David Fuelling's home page, now or in any likely
> future.
>

True, http://[EMAIL PROTECTED] won't get anyone to my homepage...but it
would get me to my IdP (assuming Google was my IdP, and offered such a
scheme).

> Ideas:
> 
> (1) define a way to include an e-mail address among the things obtainable
> with an OpenID authentication, and a transform to provide a default when
> none is declared
> 

I think the OpenID Simple Registration Extension will provide for this (If I
understand what you're meaning)
http://openid.net/specs/openid-simple-registration-extension-1_0.html

> (2a) declare that OpenID does not do e-mail based authentication and never
> will
> 

I hope this can get some more debate in some form or fashion.
:)

> (2b) name some other mechanism for e-mail based authentication and include
> it by reference, blessing said method by so doing.
> 

I think that all this discussion about email userid is moving us off track.
My original proposal was that the email maps/normalizes to a URL of an IdP
(the userid is ignored/not used).

So, '[EMAIL PROTECTED]' would be treated as if the User had entered
'http://any.edu' (the URL of their IdP/OP) into the OpenId login form.
 
Once the user agent is redirected to the 'any.edu' IdP, the IdP would be
responsible for figuring out which user is trying to login to the IdP (this
is already allowed by OpenId since we can enter a homesite/IdP/OP URL into
the login form).  The OP might authenticate me by biometric (voice,
fingerprint, DNA Sample, etc), or some other scheme, making the username
portion of my email irrelevant.

Just to be clear, I'm **not** advocating that an email get transformed into
a URL that includes the userid of the email (although, I'd be open to
entertaining the notion).


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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 09, 2006 5:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Sometimes these things will be character-for-character identical to a
> given email address by coincidence, but there's no way to enforce this
> nor any guarantee that the user controlling http://[EMAIL PROTECTED]/ is
> the same user that controls mailto:[EMAIL PROTECTED]
>

Can you provide an example (real or otherwise) of such a scenario?  Do you
really envision any domain owner giving 'http://[EMAIL PROTECTED]' to one
person, whilst giving 'mailto:[EMAIL PROTECTED]' to a different user?

 

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Hi Martin,

This is interesting.

I guess your suggestion (see your msg below) deals with a sub-topic of the
whole "should email be allowed in the OpenId login form" debate, which is
this: 

"If email is allowed in the OpenId login form, should the
mapping/normalization include the email Userid...OR, should OpenId ignore
the email address userid, and map/normalize an email address to a specific
IdP URL, allowing the IdP more flexibility in determining how to do login"?

1.) I'm not convinced that OpenId specifying a mapping/normalization scheme
that maps email addresses to IdP/OP URL's is really so bad.  We're already
mapping/normalizing www.cnn.com to its correct http scheme equivalent
(http://www.cnn.com).

2.) In Mozilla 2.0, if I type [EMAIL PROTECTED] into the URL bar, it
normalizes that (behind the scenes) to
http://beth:@google.com.  Because google.com doesn't require
user auth, I'm then redirected to http://google.com, which redirects to
http://www.google.com.

3.) The voice-activated OpenId thread on these lists comes to mind - a
Userid component of an email address may not be required, nor necessary in
many cases if a user is identified on the IdP/OP by his/her voice (for
example).

I'm curious to hear yours (and everyone else's) thoughts on this.  I don't
think we want to couple OpenId too tightly (if at all) to an email address
-- just provide an easy-to-use bridge between the two.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 09, 2006 12:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>
> One idea we came up with before was to specify that [EMAIL PROTECTED]
> becomes http://[EMAIL PROTECTED]/ and the RP should try sending an
> authenticate header for basic auth with base64 of "blah:" (empty password)
> 
> This way it's (kinda) true to the meaning of that portion of the URL
> scheme and it allows the IdP to distinguish between different users.
> 
> We'd have to check to make sure that this never conflicts with Basic
> auth implementations built into servers/frameworks, of course.
> 
> 
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/general

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Phillip,

Ok, now I understand what you're saying about "not using Http in this way".

However, I'm not advocating doing anything with the username part of an
email (this might be where we're missing each other).  I'm saying that we
just take the  +  of an email, normalize it per the OpenId
spec, and use that Http URL that we get as the URL of our IdP.   

Let me elaborate.

In a previous message, you wrote:

> > > There are two issues here:
> > >
> > > 1) The user presentation of the identifier
> > > 2) The machine presentation
> > >
> > > The two do not need to be the same. www.cnn.com works
> > perfectly well
> > > as a way to locate CNN. That is a perfectly acceptable user
> > > presentation. It is not an acceptable machine presentation and
> > > browsers SHOULD NOT accept href="www.cnn.com".

If the "user presentation" value is an email (e.g., '[EMAIL PROTECTED]'),
then what is wrong with the machine presentation (wrt OpenId) being
'http://example.com'?

The OpenId spec is already doing this with URL's in section 8.2
(Normalization).  We're mapping/normalizing 'www.cnn.com' to
'http://www.cnn.com', even though www.cnn.com is not (technically) a validly
schemed Http url.  Why not do the same with email addresses?

> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 4:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user identifier to http.
> But it has to respect the http scheme design and be crafted to avoid
> operability concerns.
> 
> http://example.com/user would be acceptable as meeting the scheme design.
> It is absolutely critical to maintain left/right hierarchy.
> 
> The username/password pieces in http were not well thought out and may
> have to be eliminated.

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Hey Dick,

Couldn't one make the opposite argument -- that most people's email address
NOT working when they plug it into the OpenId login field could actually be
a good thing? (especially in the beginning of OpenID)

I say this because such scenarios (user enters email, and RP fails because
the email doesn't yet support open id) might actually be a catalyst for more
people to use OpenId, especially if users start barking at their ISP/email
providers to support OpenId because their email isn't working correctly with
certain sites they want to use.

For example, consider the following two potential scenarios that might go
through a new user's mind when they first encounter OpenId:

Scenario #1 (WITHOUT email allowed in the OpenId login form):
User encounters an "openid enabled" site (RP ==> example.com), and decides
they are curious about this new "way" to login (simplifying, I know -- but
we're talking about a simple user).  The user pretty quickly realizes that
they need to somehow secure an Identity URL.  The typical user (my parents,
e.g.) might be inclined to say: "all my other (non-openid) sites require my
email address (usually) as a username.  Plus, since example.com still
supports email address based username+passwords anyway, why not just
continue to use that?"  Thus, the novice user who fails to see the benefits
of OpenId might just decide against OpenId because of the perceived
difficulties in using it, especially in the beginning when OpenId adoption
will be gaining traction, but not the majority method used for site login.  

Scenario #2 (WITH email allowed in the OpenId login form):  User encounters
an "openid enabled" site, and decides they are curious about the new "way"
to login.  If their email domain supports OpenId, then there's really no
reason for a novice user NOT to use OpenId -- it works with the email
address.

On the other hand, if the RP determines that the specified email address
doesn't support OpenId, it (the RP) then comes back to the User with an
educational page explaining why the email doesn't work, perhaps with a "call
your email provider and encourage them to adopt openid...and here's why".  

Anyway, this might be a different perspective on whether or not the ["oops,
your login didn't work"] is a bad thing.


> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 5:06 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Hi David
> 
> A Homesite is a new concept for users, so when they see a prompt for
> it, they will know they have one or not. They are not just typing in
> a random URL.
> 
> Pretty much every user has an email address, so a prompt asking for
> an email would suggest to user that their email will work -- which of
> course hardly any will.
> 
> -- Dick
> 

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

I wonder if it would help our discussion to clarify what is meant when we
say that an email address is an "identifier".  

While an email address does technically identify SOMETHING, here I'm using
it more as a "mapping".

So, the way I'm conceiving of things is that the email is in fact a REAL
email address.  It's just that OpenId has a procedure for using it to
forward a user to a proper IdP.

A good parallel would be the Identity URL itself.  A common user might think
of this URL as something to be clicked on, and resolvable -- A Location.
However, OpenID is instead/additionally using this URL in a slightly
different way -- to map to an identity.  Are not these two instances (email
and Claimed Identity URL) "misleading" in the same way?

(I'm actually not convinced that either is misleading, but I could be
swayed).

> -Original Message-
> From: Jonathan Daugherty [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:45 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> # So, if in a hypothetical world where we have 4 potential OpenId
> # "values" that a user could enter, AND the goal is to reduce
> # confusion, then does it really make sense to cut out the most common
> # "value" (which is an email address)?
> 
> IMHO, because using identifiers that look like email addresses would
> be misleading.
> 
> --
>   Jonathan Daugherty
>   JanRain, Inc.

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Hi Philip,

I'm not sure I understand "Please don't use HTTP this way".  

I was suggesting that the user enter an email address.  The RP then maps the
email address to a URL (which would be in the proper scheme).


> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:45 PM
> To: David Fuelling; specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Please don't use HTTP this way. That is not the semantics for http URLs.
> 
> A better scheme would be to use mailto:[EMAIL PROTECTED] or to define
> openid:[EMAIL PROTECTED]
> 
> 
> There are two issues here:
> 
> 1) The user presentation of the identifier
> 2) The machine presentation
> 
> The two do not need to be the same. www.cnn.com works perfectly well as a
> way to locate CNN. That is a perfectly acceptable user presentation. It is
> not an acceptable machine presentation and browsers SHOULD NOT accept
> href="www.cnn.com".
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > Sent: Wednesday, November 08, 2006 1:40 PM
> > To: specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > Style Identifiers
> >
> > Please see my questions/ideas enclosed...
> >
> > Thanks!
> >
> > David Fuelling
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > > Behalf Of Drummond Reed
> > > Sent: Friday, October 20, 2006 1:04 AM
> > > To: 'Recordon, David'; specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
> > > Identifiers
> > >
> > > There have been several long threads in the past about using email
> > > addresses as OpenID identifiers. The conclusion each time
> > has been to
> > avoid it. I don't remember all the arguments, but among them are:
> > >
> > > * Privacy: the last thing many users want to give a website
> > is their
> > > email address.
> >
> > This seems reasonable at first glance.  However, almost every
> > website I have a login with (today) requests my email address
> > so that the site can communicate with me electronically.
> >
> > So, if email addresses WERE used as an additional "login
> > input" for OpenId, a user who didn't want to use his/her
> > email address to login could always just use an IdP URL or
> > XRI instead (as they can today).
> >
> > Am I missing the privacy concern here?
> >
> > > * Reassignability: email addresses are not only
> > reassignable, but for
> > > some domains, they are notoriously short-lived identifiers.
> >
> > Is this really such a problem?  It seems to exist for URL's
> > in the current protocol proposal anyway.  For instance, most
> > people don't own a Domain, which means they'll be using
> > OpenID URL's that somebody else owns.  Thus, URL's are
> > reassignable too, and suffer from this in the same way
> > (although I don't really see this as a problem).
> >
> > > * Non-portability: unless you own the top-level domain, they aren't
> > > portable.
> >
> > Again, is this a problem if the email isn't the actual
> > identifier?  If we have a means of mapping an email to an
> > OpenID Identity URL, then if the email goes away (is
> > transferred or otherwise not in the control of the original
> > user), then what's the problem?
> >
> > Point 1.) Losing an email address is no different than the
> > case where a URL is lost/transferred/goes away.
> >
> > Point 2.) If a user "lost" his email address, theoretically
> > the owner of the email address (example.com, e.g.) would
> > remove the mapping from [EMAIL PROTECTED] to beth's Identity
> > Provider URL.
> >
> > Point 3.) Even if the email address domain owner failed to
> > remove this mapping, only the end-user (beth in this case)
> > would be using the email to login.  Presumably, if she
> > switched email addresses, she would use her new address to
> > login, and it wouldn't matter.  Somebody else trying to use
> > her email address would need to login to the IdP, and
> > presumably be stopped there.
> >
> > > Food for thought...
> > >
> > > =Drummond
> >
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Dick,

It seems like the same problem exists if a user types an IdP URL.  If that
URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still
encounter a problem.

Shouldn't the RP show an "educational page" if a
Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can
use?

David Fuelling

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Sunday, October 22, 2006 12:26 PM
> To: John Panzer
> Cc: Kaliya *; specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> ...
>
> If we support email addresses, then the prompt may look something
> like this:
> 
>   "email | Homesite | i-name | OpenID"
> 
> Now any user with an email address thinks they can type it into the
> box and login. This of course is not going to be the case.
> 

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

I agree.  In fact, given that most people don't know what an XRI is, we
might say there will be 3.5 times as much confusion.  

;)

So, if in a hypothetical world where we have 4 potential OpenId "values"
that a user could enter, AND the goal is to reduce confusion, then does it
really make sense to cut out the most common "value" (which is an email
address)?

> -Original Message-
> From: Jonathan Daugherty [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:30 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> # SIDE NOTE: For those who argue against email addresses in the OpenId
> # login form on the grounds of confusion, these 2 email proposals
> # should be no less "confusing" than trying to educate a user that the
> # Identity URL they type in (e.g., http://aol.com) is not their
> # identity.  Both will/would take some education.
> 
> Except that with this new feature, there would be twice as much
> confusion.
> 
> And except that an openid works both as a normal URL and as an OpenID,
> whereas an email-like-thing may work as an OpenID, but is not always
> going to work as an email even though it looks like one.
> 
> So maybe 2.5 times as much confusion. :)
> 
> --
>   Jonathan Daugherty
>   JanRain, Inc.

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Please see my questions/ideas enclosed...

Thanks!

David Fuelling

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Drummond Reed
> Sent: Friday, October 20, 2006 1:04 AM
> To: 'Recordon, David'; specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> There have been several long threads in the past about using email
> addresses as OpenID identifiers. The conclusion each time has been to
avoid it. I don't remember all the arguments, but among them are:
> 
> * Privacy: the last thing many users want to give a website is their email
> address.

This seems reasonable at first glance.  However, almost every website I have
a login with (today) requests my email address so that the site can
communicate with me electronically.  

So, if email addresses WERE used as an additional "login input" for OpenId,
a user who didn't want to use his/her email address to login could always
just use an IdP URL or XRI instead (as they can today).

Am I missing the privacy concern here?  

> * Reassignability: email addresses are not only reassignable, but for some
> domains, they are notoriously short-lived identifiers.

Is this really such a problem?  It seems to exist for URL's in the current
protocol proposal anyway.  For instance, most people don't own a Domain,
which means they'll be using OpenID URL's that somebody else owns.  Thus,
URL's are reassignable too, and suffer from this in the same way (although I
don't really see this as a problem).

> * Non-portability: unless you own the top-level domain, they aren't
> portable.

Again, is this a problem if the email isn't the actual identifier?  If we
have a means of mapping an email to an OpenID Identity URL, then if the
email goes away (is transferred or otherwise not in the control of the
original user), then what's the problem?

Point 1.) Losing an email address is no different than the case where a URL
is lost/transferred/goes away.

Point 2.) If a user "lost" his email address, theoretically the owner of the
email address (example.com, e.g.) would remove the mapping from
[EMAIL PROTECTED] to beth's Identity Provider URL.

Point 3.) Even if the email address domain owner failed to remove this
mapping, only the end-user (beth in this case) would be using the email to
login.  Presumably, if she switched email addresses, she would use her new
address to login, and it wouldn't matter.  Somebody else trying to use her
email address would need to login to the IdP, and presumably be stopped
there.

> Food for thought...
> 
> =Drummond


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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[David Fuelling]

Hi All,

Sorry to re-open this can of worms, but I'm just getting a chance to chime
in.  I actually think David Recordan's idea re: email address to URL
resolution would be a great idea!  

My vote would also be to allow an Email address to map to an Identity
Provider URL.   NOTE:  The email address does not map to a Claimed
Identity nor to a Verified Identity  (This is key!) 

Assuming I'm reading David R's proposal correctly, I think the only
difference between the two proposals is that in mine, the IdP doesn't need
to know what email address was entered (remember, the email is NOT the
identity -- it's just a mapping).

Here it is



1.) User enters an email address into an RP's OpenId login box.
2.) Behind the scenes, the RP resolves the email address to an OpenId URL
via [Resolution Procedure] below.
3.) If the email address resolves to an Identity Provider URL, then the RP
continues the OpenId protocol as if the user had entered the Identity
Provider URL.
4.) If the email address does NOT resolve to an Identity Provider URL, then
the RP SHOULD display a page that says something like: "We're sorry, your
email address doesn't not yet support Open ID.  Please try a different
identifier type."  On the same page should be some verbiage to help educate
the user about what OpenID identifiers are, and possibly how email addresses
map to them.  Additionally, this could be a page to educate the user about
XRI's, and the other parts of OpenId that are appropriate.

###
[Resolution Procedure]:  An email address resolves to a valid OpenId IdP
URL, per the following procedure.

A1.) For a given email address of the form '[EMAIL PROTECTED]' and a
corresponding domain of the form 'http(s)://domain.tld/, a RP SHOULD attempt
OpenID URL discovery (See OpenId Auth 2.0 section 7.3 - Discovery) on the
following URL's that are resolved out of the specified email address:

1.) http://.
2.) http://www..

The above URL's MUST be resolved by replacing the  and  values
with corresponding values from the specified email address' 'domain' and
'tld' parameters.  In addition, resolution of the above 2 alternate URL's
should be done via a HEAD request to all of the URL's first, followed by a
GET request to all of the URL's if no URL produces a valid Yadis Resource
URL via the HEAD method.

A2.) Per the OpenId spec, if URL Discovery fails, then HTML-based discovery
should be attempted on the same URL's, in the same manner as above.




SIDE NOTE: For those who argue against email addresses in the OpenId login
form on the grounds of confusion, these 2 email proposals should be no less
"confusing" than trying to educate a user that the Identity URL they type in
(e.g., http://aol.com) is not their identity.  Both will/would take some
education.

Thanks!

David Fuelling
[EMAIL PROTECTED]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Recordon, David
> Sent: Thursday, October 19, 2006 9:46 PM
> To: specs@openid.net
> Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> In meeting with a large service provider this week, an issue around end
> user usability came up.  The concern they expressed was that users are
> know how to enter usernames or email addresses to initiate the login
> process.  While directed identity allows the user to enter
> "example.com", they feel that it still is a bit of a stretch at this
> time for any major deployment of OpenID.
> 
> 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.  The idea is that the RP splits the string on the "@" and
> then treats "example.com" as the IdP Identifier.  This thus doesn't
> actually require any changes to the protocol itself.  Any Relying Party
> can do this today, but they desire to see this as part of the
> specification itself so they wouldn't be doing anything special.
> 
> Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
> proposal, in case one, openid.identity would be set to
> "http://openid.net/identifier_select/2.0"; and then instead of
> openid.portable being empty, in this case "[EMAIL PROTECTED]" would be
> sent to the IdP.  While not perfectly mapping to the definition of the
> openid.portable field, it doesn't seem like that much of a hack to do
> this.
> 
> While I certainly am not looking to re-kindle the "Why a URI?" debate,
> http://[EMAIL PROTECTED] is also technically a valid URI.  It is used in
> many cases by browsers to provide a username when making a web request.
> 
> So while this is a lit

RE: Request for comments: Sorting fields in signature generation

[David Fuelling]

Just for clarification -- if duplicate parameters of the same name are NOT
allowed by the spec, would one still be able to encode multiple values in
the same key/value pair?  Wouldn't this accomplish the same result as
allowing duplicate key names?

Not sure if this would be a bad idea, or not, but something like the
following that separates the two error messages using a semi-colon (or some
other character), and utilizes an escape character if a semi-colon is
actually part of the message:


Key | Value
+---
mode| error
error   | This\; is error message1;This is error message2.

I'm not convinced this is the way to go, but something to consider, perhaps?


David

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Josh Hoyt
> Sent: Tuesday, September 26, 2006 7:13 PM
> 
> I think the real topic of this discussion is whether or not multiple
> parameters with the same name should be allowed by the specification.

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

RE: Backwards compatibility

[David Fuelling]

Josh,

Just a point of clarification -- As worded, your #1 says that any OpenId 2.0
message would work in any OpenId 1.1 system, which (from my perspective)
implies that the 2.0 protocol cannot implement any (significant) message
features that aren't defined in 1.1which would tend to imply that the
two protocols are identical (since 1.1 is already defined).

Are you really meaning to ask the following instead:

#1R: OpenId 2.0 systems MUST implement and support all of the messages in
OpenId 1.1.

#2R: It is possible for implementations to differentiate between OpenID
1.1 and 2.0 and to construct appropriate messages. In essence, it's a
different protocol, and #1R is not required.



Thanks!

David Fuelling

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Josh Hoyt
> Sent: Wednesday, September 20, 2006 4:31 PM
> To: specs@openid.net
> Subject: Backwards compatibility
> 
> When making and evaluating proposals, there have been many references
> to backwards compatibility. I'm not sure that everyone has the same
> idea what it means to be backwards compatible.
> 
> There are at least two meanings that I can see:
> 
> 1. Messages that are valid OpenID 2.0 messages are also valid OpenID
> 1.1 messages
> 
> 2. It is possible for implementations to differentiate between OpenID
> 1.1 and 2.0 and to construct appropriate messages. In essence, it's a
> different protocol.
> 
> I've been focused on maintaining (1). How do you see it?
> 
> Josh
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

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