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

2009-06-09 Thread David Fuelling
David,

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

david

On Tue, Jun 9, 2009 at 6:36 PM, David Recordon da...@sixapart.com 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)http://tools.ietf.org/html/draft-nottingham-site-meta-01%29or
  now WebFinger (
 http://code.google.com/p/webfinger/)?http://code.google.com/p/webfinger/%29?
  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


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

2009-06-09 Thread David Fuelling
On Tue, Jun 9, 2009 at 7:09 PM, Breno de Medeiros br...@google.com 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)

2009-06-09 Thread 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 a...@yahoo-inc.com 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: New OP-MultiAuth Draft Published

2009-01-19 Thread David Fuelling
On Sun, Jan 18, 2009 at 10:41 PM, Paul Madsen paulmad...@rogers.com 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

2009-01-18 Thread 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


Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1

2008-12-31 Thread David Fuelling
On Tue, Dec 30, 2008 at 7:00 PM, Peter Williams pwilli...@rapattoni.comwrote:

  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 RD. (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, including
   which OP asserts for them, and also including what an RP can do with a
   

Re: Proposal to form Discovery Working Group

2008-12-27 Thread David Fuelling
On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp 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


Re: non-standard login mechanism

2008-11-17 Thread 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: [OpenID] OpenID Extension to handle Emails Addresses?

2008-10-30 Thread 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


Re: OpenID Trusted Authentication Extension

2007-08-27 Thread 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

2007-07-31 Thread 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 
 spechttp://openauth.googlegroups.com/web/OAuth%201.0%20-%20Draft.rtf?gda=s1UWzkYySf4xbkOgHBZma37zlp9GzEEF__EUK3CcB8RrKx_-nmG1qiJ7UbTIup-M2XPURDT_25fdK7wDxUtwqL26wW_WahD8rT1PnKl_iYB0spTcFQ.


 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).


snip


snip



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


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

2007-06-11 Thread 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?

2007-06-08 Thread 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: Questions about IIW Identifier Recycling Table

2007-06-07 Thread 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


Re: Questions about IIW Identifier Recycling Table

2007-06-07 Thread 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:
a href= http://me.example.com#1234;http://me.example.com/a

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


Questions about IIW Identifier Recycling Table

2007-06-05 Thread 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]

2007-02-28 Thread 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

snip
 
 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 understatementsome talk/understatement 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


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

2007-02-10 Thread 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.

..snip..

 [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


RE: Proposal: SMTP service extension for Yadis discovery

2007-02-05 Thread 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:

Service
!-- eMail to OpenId URL Transformation Service --
Typehttp://ext.openid.net/emailTransform/Type
URI priority=1http://example.org/[username]/URI
/Service

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:

Service
!-- eMail to OpenId URL Transformation Service --
Typehttp://ext.openid.net/emailTransform/Type
URI priority=1http://example.org/~[username]/URI
/Service

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

2007-01-23 Thread 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: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-11-10 Thread 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


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

2006-11-09 Thread 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 domain + tld 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


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

2006-11-09 Thread 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

2006-11-08 Thread 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

proposal

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://domain.tld
2.) http://www.domain.tld

The above URL's MUST be resolved by replacing the domain and tld 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.

/end proposal


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 little funky, I really think the increased usability
 offered by describing what a RP should do when a string like this is
 entered seems to outweigh the potential conceptual confusion.
 
 Thoughts?
 
 --David
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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

2006-11-08 Thread 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

2006-11-08 Thread 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

2006-11-08 Thread 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

2006-11-08 Thread 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