Re: experimental namespace for openid.net

2009-07-10 Thread George Fletcher

+1 to http://experimental.openid.net

It would be good to add this to the repository work Breno and John are 
doing as having a registry for experimental URIs would be good as well.


Thanks,
George

Dirk Balfanz wrote:

[+gene...@openid.net mailto:gene...@openid.net for a broader audience]

On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com 
mailto:balf...@google.com wrote:


Hi guys, 


Google would like to launch a feature in which we're allowing our
Google Apps hosted domains to become OpenID providers. The
authentication part of it is pretty simple - Google is already
logging in users to their apps, so we can also host an OP endpoint
for those domains and send assertions back to Relying Parties.
What is more difficult is the discovery part. We have been working
with the XRI TC to define a XRD-based discovery protocol that
would allow this kind of hosting of discovery documents on behalf
of our customers. 


We believe that providing proof-of-concept implementations drives
standardization processes forward, so in this spirit we want to
launch this feature in the near future, using a discovery protocol
that as far as we can tell meets all the requirements of what the
XRI TC is currently converging on, but which has not been vetted
as an official standard (it's a chicken and egg thing - without
PoC no standards, without standards by definition no
standards-compliant implementations).

While we were tossing around ideas 
http://markmail.org/message/ixc5led2lobdwij2in the

standardization committees we just used random identifiers for new
XML namespaces, etc. that we would need for this discovery
protocol. Now that we're about to launch we need to decide what to
call these things. We would like to use a namespace
in http://specs.openid.net/... because we want this kind of
discovery protocol to be part of OpenID, but we can't really use
them because we don't have a next-generation discovery protocol yet. 


So what should we use? How
about http://experimental.openid.net/... ? That way, Relying
Parties know that what we're trying to do is be a part of the
OpenID community and bring the protocol forward. On the other
hand, this would also be a signal to the RP that they're using a
feature that has not been vetted as a standard yet. 


For example, a discovery document for a domain balfanz.net
http://balfanz.net at Google might look like this (notice the
experimental namespace and the XML elements using it):

?xml version=1.0 encoding=UTF-8?
xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)
  ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#;
  ds:SignedInfo
  ds:CanonicalizationMethod 
Algorithm=http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets; /
  ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1; 
/
  /ds:SignedInfo
  ds:KeyInfo
  ds:X509Data
  ds:X509Certificate
  MIICgjCCA...
  /ds:X509Certificate
  ds:X509Certificate
  MIICsDCCAhmgAwIB...
  /ds:X509Certificate
  /ds:X509Data
  /ds:KeyInfo
  /ds:Signature
  XRD
  CanonicalIDbalfanz.net http://balfanz.net/CanonicalID
  Service priority=0
  Typehttp://specs.openid.net/auth/2.0/server/Type
  Typehttp://openid.net/srv/ax/1.0/Type
  Typehttp://specs.openid.net/extensions/pape/1.0/Type
  URIhttps://www.google.com/a/balfanz.net/o8/ud?be=o8/URI
  /Service
  Service priority=0 
xmlns:experimental=http://experimental.openid.net/google/2009/07/xmlns/;
  Typehttp://www.iana.org/assignments/relation/describedby/Type
  MediaTypeapplication/xrds+xml/MediaType
  
experimental:URITemplatehttps://www.google.com/accounts/o8/user-xrds?uri={%uri}

https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D/experimental:URITemplate
  experimental:NextAuthorityhosted-id.google.com
http://hosted-id.google.com/experimental:NextAuthority
  /Service
  /XRD
/xrds:XRDS

What do you guys think?

Dirk.




___
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: OAuth Hybrid and UI ML?

2009-06-16 Thread George Fletcher
Will these lists be open for reading to the community? I'd like to keep 
up with what's happening in both these groups.


Thanks,
George

David Recordon wrote:
Once the working groups are approved and someone is willing to 
moderate new members on the list to make sure they've signed 
contribution agreements before posting, I can make the list itself.


--David

On Jun 11, 2009, at 6:21 PM, Allen Tom wrote:


Hi Nat,

How does one create a mailing list? At least with regards to the 
OpenID UI WG, we're just mailing each other directly.


Allen



Nat Sakimura wrote:
Hi. 

I just found out that the Mailing list for OAuth Hybrid WG and UI WG 
are not listed on http://openid.net/mailman/listinfo/ .  
http://openid.net/mailman/listinfo/


To make sure equal participation, we should make it possible for 
people to find out about them. 

Are they established at all? Where is the discussion being conducted 
right now? 


--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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


___
specs mailing list
specs@openid.net mailto: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: Should we recommend that return_to url is always HTTPS? What about realm?

2009-05-14 Thread George Fletcher

John,

By PPID do you mean the InfoCard unique User:RP identifier? Or are you 
referring to the use of pseudonymous identifiers within OpenID?


If the latter, I didn't see the thread that was suggesting that the 
pseudonymous identifiers match the realm. I would be against that 
suggestion. The spec requires the RP to do discovery on the pseudonymous 
identifier to prove that the OP that returned the response is 
authoritative for the pseudonymous identifier. With this mechanism, the 
realm should not need to match the identifier.


Thanks,
George

John Bradley wrote:

Luke,

From a URI point of view the two URI are different and it can't 
be considered steeping up security.


I understand that is what would normally happen but it violates some 
basic principals.


It also compromises RP discovery.  

A wijldcard in the realm may be the better solution.  Though you may 
not want to include matching all protocols.


In the other thread we are discussing PPID like identifiers.   If they 
are based on the realm as people are discussing,  introducing 
wildcards etc introduces the question of realm normalization on that side.


John Bradley


On 14-May-09, at 11:25 AM, Luke Shepard wrote:

So, RP delegation sounds like a very general solution to the problem, 
and seems okay to push for. But I think there’s a much simpler 
solution that solves the specific problem I described below:


RULE:
  If the realm is http, then the return_to can be either http or https.

So this would be legal:

realm: *http*://open.lukeshepard.com/
return_to: *https*://open.lukeshepard.com/openid/receiver.php

This would NOT be legal – you can’t go the other way.

realm: *https*://open.lukeshepard.com/
return_to: *http*://open.lukeshepard.com/openid/receiver.php

So, the receiver should be allowed to INCREASE its security level 
from the realm, but not decrease.


This is analogous to wildcards for the protocol instead of just 
subdomain. Another alternative would be to have explicit wildcards 
for the protocol, or to allow realms with relative protocols, like:


explicit wildcard: *://open.lukeshepard.com
relative protocol: //open.lukeshepard.com



On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote:

I agree that RP delegation should be possible and even desirable.

To do that safely the OP needs to do RP discovery over SSL or
discover a XRD with detached sig for the RP.

Otherwise you open up Man in the Middle attacks.  


My point was that in the existing spec to prevent interception of
tokens and attributes,  the Realm that is displayed by the OP to
the user needs to match where the assertion is sent.

I agree that this is something that should be addressed in openID
2.1 ether for XRD with dsig or via XRDS with TLS.

John B.

On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:

I don't see why a realm shouldn't be able to delegate to a
return_to URL the same way that a user id can delegate to an
OP endpoint. This includes delegating from http to https, or
even to a different domain altogether. Over on the XRI TC
we've been talking about how to do this securely, e.g., by
signing the XRD that does the delegation:
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile
 
Dirk.


On Wed, May 13, 2009 at 7:43 PM, John Bradley
jbrad...@mac.com wrote:
 Luke,
 Realm was called trust_root in 1.1, and is a bit like
audience restriction
  in SAML.
 It is the display version of the return_to, and also used
for RP discovery
 by the OP.
 I am not certain what the problem is with it being https: if
the return_to
 is https:.
  There is explicitly no connection to be inferred by DNS
authority between
 URI differing in scheme.   
 Differentiating TLS by its own scheme is a decision we have

to live with.
 The user should consent to authentication for the site they
are logging
  into.
 http://open.lukesheppard.com and
https://open.lukesheppard.com could
 be different sites.
 If the RP has both HTTP and HTTPS the best practice would be
to always use
  the https: version for realm so that RP discovery cant be
spoofed via DNS.
 Regards
 John B.
 On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote:
 
 Date: Tue, 12 May 2009 23:10:38 -0700
 From: Luke Shepard lshep...@facebook.com
 Subject: Should we recommend that return_to url is always
HTTPS? What
  about realm?
 To: OpenID Specs Mailing List specs@openid.net
 Message-ID: c62fb26e.bce7%lshep...@facebook.com
mailto:c62fb26e.bce7%25lshep...@facebook.com 
  Content-Type: multipart/related;
 boundary=_004_C62FB26EBCE7lshepardfacebookcom_;
 

Re: Should we recommend that return_to url is always HTTPS? What about realm?

2009-05-14 Thread George Fletcher
OK, thanks. I think I understand how you are relating realm to PPID. I 
agree that we probably have to generate the PPIDs on the user:realm pair 
(note, it would be very nice if realm were included in the association 
request; but that's a different discussion). Even this causes some 
problems if a set of RPs share the same realm... but it's the best that 
can be done right now with the current spec.


While realm normalization isn't required for PPIDs to work and be 
unique, practically we'll have to do something so that users have a 
least a chance of a consistent experience. Note that this will pretty 
much require an RP to never change their realm because if they do, all 
the PPIDs will regenerate and the user's data will be lost.


Thanks,
George


John Bradley wrote:

George,

By PPID I am referring to a pairwise pseudonymous identifier like PPID 
in info-card or the IDs Google uses.


The 2.0 spec talks about OP identifiers being used to allow the user 
to select an identity at the OP. (badly and in a confusing way)


No place in 2.0 talks about pseudonymous  identifiers of any sort.
So the question is if the user doesn't want there activity 
correlated,  or a RP for PII legal reasons doesn't want a correlatable 
identifier for the user  how should the OP produce such an identifier.


Further if that type of identifier is required by the RP how would 
they indicate that.


The realm would only be used by the OP to produce the private 
personal identifier.


Doing this raises additional questions about how to normalize the Realm.
Do you want to produce the same PPID for all of these?

http://example.com
http://www.example.com
https://www.example.com
http://www.example.com:80
http://www.example.com:443
https://www.example.com:443
http://www.example.com/

The RP might so to make it at least predictable there should be some 
normalization rule.


I am sure Breno will jump in I know this is one of his issues.

So while all openIDs are on some sense pseudonymous,  I was referring 
to the pairwise ones.


Regards
John B.

On 14-May-09, at 1:17 PM, George Fletcher wrote:


John,

By PPID do you mean the InfoCard unique User:RP identifier? Or are 
you referring to the use of pseudonymous identifiers within OpenID?


If the latter, I didn't see the thread that was suggesting that the 
pseudonymous identifiers match the realm. I would be against that 
suggestion. The spec requires the RP to do discovery on the 
pseudonymous identifier to prove that the OP that returned the 
response is authoritative for the pseudonymous identifier. With this 
mechanism, the realm should not need to match the identifier.


Thanks,
George

John Bradley wrote:

Luke,

From a URI point of view the two URI are different and it can't be 
considered steeping up security.


I understand that is what would normally happen but it violates some 
basic principals.


It also compromises RP discovery.
A wijldcard in the realm may be the better solution.  Though you may 
not want to include matching all protocols.


In the other thread we are discussing PPID like identifiers.   If 
they are based on the realm as people are discussing,  introducing 
wildcards etc introduces the question of realm normalization on that 
side.


John Bradley


On 14-May-09, at 11:25 AM, Luke Shepard wrote:

So, RP delegation sounds like a very general solution to the 
problem, and seems okay to push for. But I think there’s a much 
simpler solution that solves the specific problem I described below:


RULE:
 If the realm is http, then the return_to can be either http or https.

So this would be legal:

realm: *http*://open.lukeshepard.com/
return_to: *https*://open.lukeshepard.com/openid/receiver.php

This would NOT be legal – you can’t go the other way.

realm: *https*://open.lukeshepard.com/
return_to: *http*://open.lukeshepard.com/openid/receiver.php

So, the receiver should be allowed to INCREASE its security level 
from the realm, but not decrease.


This is analogous to wildcards for the protocol instead of just 
subdomain. Another alternative would be to have explicit wildcards 
for the protocol, or to allow realms with relative protocols, like:


explicit wildcard: *://open.lukeshepard.com
relative protocol: //open.lukeshepard.com



On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote:

   I agree that RP delegation should be possible and even desirable.

   To do that safely the OP needs to do RP discovery over SSL or
   discover a XRD with detached sig for the RP.

   Otherwise you open up Man in the Middle attacks.
   My point was that in the existing spec to prevent interception of
   tokens and attributes,  the Realm that is displayed by the OP to
   the user needs to match where the assertion is sent.

   I agree that this is something that should be addressed in openID
   2.1 ether for XRD with dsig or via XRDS with TLS.

   John B.

   On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:

   I don't see why a realm shouldn't be able

Re: Requiring Pseudonymous Identifier

2009-05-13 Thread George Fletcher
+1 to using AX and the identity-less flow Andrew identified recently for 
claims/attribute based access to web sites.


There are some 3rd-party asserted issues in regards to the validity of 
the attribute value but that's a whole different discussion:)


Thanks,
George

Luke Shepard wrote:
Agreed. If all you want is a group, then I’d think that the response 
would just not include an identifier.


You could use an extension, perhaps AX, to request information about 
the group a user belongs to.


For example, if you wanted to understand company membership, you could 
request and return only http://axschema.org/company/name.


On 5/12/09 11:08 PM, Martin Atkins m...@degeneration.co.uk wrote:

Chris Messina wrote:

 So, imagine I use directed identity in a school application...
when I sign
 in to the OP, it will return something like
schoolname.edu/student as the
 identifier.


Overloading our existing concept of an identifier to support
identifying
a group worries me. Most consumers expect an identifier to be for a
person and are designed around this principle.

I think if groups are useful their design should be different such
that
consumers are able to distinguish between a user and a group.

___
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: Requiring Pseudonymous Identifier

2009-05-13 Thread George Fletcher
I'm perfectly fine with using RP discovery as a mechanism for the RP to 
specify what policy it requires. I believe that unsolicited assertions 
are going to become more common, so we need to support it.


What I don't want OpenID to do is specify the actual syntax of the 
pseudonymous identifier. I agree that the RP has to trust the OP (in 
some sense) or make it's own determination that the OP is not honoring 
the RP's wishes and then take some action.


For RP's behind firewalls, it would be nice to allow them some mechanism 
other than RP discovery to assert their requirements, but that should 
preclude the discover option.


Thanks,
George

Andrew Arnott wrote:
leaves out the scenario of unsolicited assertions.A new directed 
identity value that the RP passes to the OP to indicate it wants a 
psuedononymous identifier.  Consider this:


An OP needs to perform RP discovery (already), and probably does so 
before sending an unsolicited assertion in order to find out what the 
assertion receiving URI would be for a given realm.  DNOA does this 
already.  If that RP's XRDS document included a TypeURI element that 
had a special psuedononymous-identifier-only-please value the OP could 
pick up on this, and send the unsolicited assertion using the 
appropriate type of claimed_id.


Likewise, when an RP sends an ordinary directed identity request to an 
OP, the OP would again notice the RP's XRDS during RP discovery and 
see what kind of identifier the RP wants and assert accordingly.


Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP 
discovery at all.  Perhaps to help the RP detect whether the OP 
respected its wishes would be to send a PAPE extension or some other 
openid.* parameter to say yes, this is a pseudo- identifier.  RPs 
have no way to analytically be certain that some identifier is 
psuedononymous anyway, so ultimately the RP has to trust the OP 
(whether implicitly or through a white list is up to the RP).


--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it. - Voltaire



On Wed, May 13, 2009 at 8:44 AM, George Fletcher gffle...@aol.com 
mailto:gffle...@aol.com wrote:


I don't think OpenID should specify how pseudonymous identifiers
are generated. That should be up to the OP. But I like the idea of
using a fixed URI as the claimed_id value to specify the behavior
desired by the RP. If, however, we need to grow this to cover
anonymous based identifiers (i.e. the claims based models from
earlier in this thread) then it might make sense to look at a PAPE
extension that covers the type of identifier requested.

Thanks,
George


Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into sectors.
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in
their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote:
 


On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
   


Reason for using RP's Subject in XRD instead of simply
using realm is
to allow for something like group identifier.
 


would you elaborate on the group identifier concept?

   


This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible
to utilize AX
so that it will only be a profile that does not
require a WG.

So shall we start discussing which direction we want
to go forward?
 


sure!

   





 


___
specs mailing list
specs@openid.net mailto: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

2008-11-11 Thread George Fletcher
Great notes! Thanks!

Martin Atkins wrote:
 Here's the output from today's IIW session on this:


 2.0 has been finalized
 bunch of implementations
 found lots of spec bugs

 also gone and done oauth and email addresses and other things. Can we 
 support these in the core spec?

 - Making the spec more readable and fixing bugs (eratta)
- Delegation
- Error handling
 - Adding a security appendix
- could be a separate document referred to by the spec
- possibly produced by separate group
- Who controls this security page?
  - Security committee could look after this.
  - or Allen at Yahoo! will be editing a security document
 - Clarifying XRI
- Currently there's no firm message about whether RPs MUST support 
 XRIs or not.
- Need to clarify how exactly XRI should be used with OpenID.
- Similar to the whitelist question.
 - Clarify if RPs can white or blacklist what OPs they accept, and 
 vice-versa.
- Discovery of type of identifiers an RP supports.
 - Clarifying IRI
 - Updating discovery. Possibly including the new-fangled XRD discovery.
 - Clarifying whether association over SSL must/can use diffie-hellman.
 - Discovery of support of checkid_immediate.

 Exploratory work:
 - Signature mechanisms. Looking at additionally supporting the 
 mechanisms defined in OAuth so that they can be closer together.
- Possibly deprecating the current signature mechanism.
- Public keys?
 - Email-shaped identifiers for OpenID
- Could be a separate working group?

 There was consensus that email-shaped identifiers would be worked on by 
 a separate group and possibly rolled into 2.1 if it's done in time.

 - Smart/rich clients?
- Could be in this WG unless it ends up being a big change in which 
 case it could be its own WG.
- There's another session about this.

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

   

-- 
Chief Architect   AIM:  gffletch
Identity Services Work: [EMAIL PROTECTED]
AOL LLC   Home: [EMAIL PROTECTED]
Mobile: +1-703-462-3494
Office: +1-703-265-2544   Blog: http://practicalid.blogspot.com

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


Re: This is user's URI for Assertion Quality Extension

2008-09-05 Thread George Fletcher
 
 (learned from Sun's implementation) is I am a member of Sun but you 
 don't know who. Is this the only variation of OpenID services that 
 any company will ever come up with? I'm thinking here of membership 
 levels, such as This employee is technical support, this employee is 
 sales. and This employee works at an entry-level position, this 
 employee is a manager. - all of which may be better suited to AX with 
 the OP not letting its users set their own attributes, and since many 
 sites either wouldn't use the granularity or wouldn't need it, there's 
 not much reason here for sticking it in the Assertion Quality spec. 
 But we could start out with the 3 distinctions known, and add others 
 only if they became appropriate.
Even in the 3 distinctions you've identified, could they be handled by 
AX? That seems to me to be the natural fit. Even in the case of what SUN 
did, I think AX would be better suited rather than the implicit 
statement that SUN made.

 Hmm . . . the RP could process a URI to extract OP-Local and create 
 one account for the entire site (*if* it knew that the user's account 
 with that OP was anonymous). Here's the challenge: in cases of 
 sub-domains, what's the site? Is there a meaningful difference between 
 tech.site.com and sales.site.com?
I'm confused by the relationship between OP-Local and the entire site. 
The OP-Local identifier is the OP's identifier for the user (if it's 
provided). However, it's still an identifier for the individual. I 
suppose you could associate it with this OP is authoritative for this 
OpenID but I think that's about as much as can be assumed.

Thanks,
George

 -Shade

 At 8:17 AM -0400 9/5/08, George Fletcher wrote:
 SitG Admin wrote:
  What's the use-case?


  If the RP doesn't care about distinguishing between users that have 
 accounts at a site but identify themselves as such anonymously, it 
 can reclassify them as users that have accounts at a site, 
 consolidating what could be a large number of identities into a 
 single account. (This is largely a convenience for the Relying 
 Parties, reducing database clutter but perhaps the performance hit 
 wouldn't be noticed anyway?)

 How would the OP know if the user it's authenticating is a member at 
 the RP? It's not required to keep that information? I suppose OPs 
 could keep track of all the RP's they've sent a particular OpenID 
 to... but it might not be trivial for the OP to extract that 
 information and make a determination that a particular OpenID falls 
 into the classifications you've listed.

 Also, couldn't the RP keep track of the op_local value with the 
 claimed_id to help reduce clutter in the RP db? This would help with 
 user entered claimed_id's. Of course in directed identity there is 
 only one identifier, but that shouldn't change on a regular basis for 
 the same user.

 Yes, the OP can hand out a totally random identifier each time the 
 user logs in, but that isn't the spirit of directed identity. The 
 spirit is for the OP to create a unique identifier for the 
 relationship of user:OP:RP and maintain that relationship across time.
  RP's may want to discriminate between users that use a real URI 
 and those that only use OpenID anonymously, just as users may want 
 to experiment with new sites using a unique (randomly generated) URI 
 that can't be associated with their accounts elsewhere, and then use 
 their main URI if they decide they like the RP's services. (I'm 
 hoping that others here will volunteer their own specific use-cases 
 or what they *could* do with such information were it asserted by an 
 OP.)

 So I can see a use case for an RP to know the real identifier for 
 linking data for the user at the RP with other data by that user 
 across the web. This seems to me to be the benefit to put before 
 the user. If you use a correlatable OpenID at our site, then we can 
 provide you these additional benefits (e.g. automatically find people 
 that know you that also use this site).

 Note that it's possible to provide these same benefits without using 
 correlatable identifiers, but it requires a service that knows the 
 mapping.
  One form of discrimination could be encouraging users to have a 
 real URI by giving them more features - reward them for adapting 
 to the Web 2.0 model and using their OpenID around the web. Another 
 could be swifter expiration of new accounts under the presumption 
 that new users who use an anonymous URI are just experimenting with 
 the service (this would be both a performance convenience for RP's 
 as described above, and a complement of the encouragement more 
 immediately above, instead *dis*-couraging users from using an 
 anonymous URI for long-term use). (Since a user could still create 
 multiple accounts on one or more sites and use each of them as a 
 real URI; such discrimination wouldn't reduce the user's ability 
 to compartmentalize their identity and maintain privacy.)

  -Shade

Re: IDMML (was RE: Using email address as OpenID identifier)

2008-04-02 Thread George Fletcher


Drummond Reed wrote:
 Dick Hardt wrote:

 :-) ... that label would be more accurate. There is lots of work to be
 done to make OpenID simpler for users. I think that what will be easy
 for users is something provided by the browser that lets the user
 click to initiate a login or registration. No typing is better then
 any typing! Back when we started working on the protocols we could not
 expect this kind of functionality to be in the browsers. Now that
 awareness is higher, having it built into the browser is feasible. I
 of course am biased given the work we have done with Sxipper
 http://sxipper.com :)
   
 For the majority of users, this is probably the most likely path of
 introduction to OpenID. Note that it's not just about allowing the user
 to do something with one click, but also about being proactive and
 informing the user that they can login to a site with an identity they
 already have. This can be as simple as telling the browser identity
 agent (e.g. sxipper) which email addresses the user has and letting the
 identity agent figure out which OpenID's the user has that they don't
 even know about.

 George Fletcher wrote:

 I think relying party sites that support OpenID could do more to make it
 clear on their home pages that they support OpenID (as often it's hidden
 behind another click). This could be as simple as some link tags that
 advertise support for OpenID. Maybe a link to the XRDS doc describing
 the services of the site. Then the identity agent can discover the
 relying party OpenID return_to endpoint and log the user in directly.
 Can be used to solve a phishing problem and makes the experience easy
 for the user.

 Some related thoughts 
http://practicalid.blogspot.com/2007/06/clients-to-rescue.html

 http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
 markup.html
 

 George, I read your two posts with great interest...and then noticed that
 they were last summer!

 You are a man ahead of your time.

 Where has discussion of your IDMML gone since your posts?

 =Drummond
Unfortunately, not as far as I'd like :(  I've not been able to get back 
to the ideas and take them farther. With the other things that have 
happened in the last 6 months there are needed revisions. Maybe this 
could be a discussion at IIW (if there is enough interest)?

At the time there was less consensus around XRDS as a service 
description/meta-data markup. With that changing, the time is better 
to move this forward. I suspect there are significant synergies with 
what Peter hinted at in the work with XRDS, IDP Discovery, and SAML. It 
would be great if identity agents could be the glue that binds the 
different identity systems together for the user (until we on the 
technology side get closer to real convergence:).

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


Re: Proposal: An anti-phishing compromise

2007-02-02 Thread George Fletcher




That depends completely on
what the authentication mechanism and even one time use tokens can be
phish'd and used to compromise accounts. For example, the rogue site
gets the SecurId and then immediately logs in on its own using the
supplied credentials. Those credentials establish a session that can
then be used to compromise the account. So it helps, because the rogue
site can't go back and authenticate again after the session is over,
but it could easily do plenty of damage (or set up back doors) with
just one phish'd session.

What authentication mechanisms are not phish'able and yet don't require
client side code? How many are viable to a user to participate in? I
have a SecurId and it can be a pain even though it protects my
account. Do users want to deal with this level of inconvenience? (The
should, but will they?)

Thanks,
George

Johnny Bufu wrote:

On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
  
  but I'm still not sure how this helps with
the phishing problem. As you pointed out John, the issue is a rogue RP
redirecting to a rogue OP. So the rogue OP just steals the credentials
and returns whatever it wants.

  
  
In this case, the rogue RP is not interested at in the the auth
response from the rogue OP (or for that matter from the legitimate OP);
just in stealing the user's credentials.
  
  
The phishing field prevents the phisher to later use these credentials
on a legitimate RP (which will be contacting the legitimate OP) to
impersonate the user -- if the RP enforces "phishable = no".
  
  
Johnny
  
  
  
  
  



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


Re: OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher
+1 simple and straight forward

Just curious about uses cases where the required authentication level 
changes over time.  For instance, a use case where to view my stock 
portfolio just requires password, but doing a trade requires 
voicebio.  Is the expectation that authentication events can be 
treated as standalone? or that it's the RP's responsibility to manage 
the combinations based on the identifier?

One final question... Is it valuable to provide a way to request two or 
more authentication methods be employed in the authentication event?  
For example, administrators of a site must use both password and 
hardotp.  Everyone else just needs password.

Thanks,
George


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


Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher





Paul Madsen wrote:
Hi
George, for your use case below, why would not the RP just ask for the
user to be up-authenticated at the desired higher level when necessary?
  

So in the draft... how does
the RP ask for the user to be "up-authenticated"? The authentication
request parameters do not in any way indicate a previous
authentication, and the extension parameters also don't include any way
to indicate a previous authentication. That is what I really meant by
the authentications being "standalone". The RP may relate the two
authentications in some way because it requested both. Maybe that's
good enough.


Are you asking whether the RP should be allowed to ask the user to
re-present their URI in order for this to happen? And thereby
effectively treating each event as disconnected/standalone?
  

Ideally, the user would not
be able to change their URI when being re-challenged based on
max_auth_age but I guess the RP should make sure to code for that edge
case.


Wrt combinations, I know from experience that the alternative to
allowing for RPs to specify combinations is a combinatorial explosion
in the number of mechanism identifiers.
  

I agree that the combinations
can explode... but they are also useful. For example to hack my
account you need both my "password" and my "hardotp". That's two
"secrets" that need to be determined for my account to be compromised.
(Not that this doesn't stop phishers).

Thanks,
George


Paul
  
  
George Fletcher wrote:
  
  +1 simple and straight forward


Just curious about uses cases where the required authentication level
changes over time. For instance, a use case where to view my stock
portfolio just requires "password", but doing a trade requires
"voicebio". Is the expectation that authentication events can be
treated as "standalone"? or that it's the RP's responsibility to manage
the combinations based on the identifier?


One final question... Is it valuable to provide a way to request two or
more authentication methods be employed in the authentication event?
For example, administrators of a site must use both "password" and
"hardotp". Everyone else just needs "password".


Thanks,

George



___

general mailing list

[EMAIL PROTECTED]

http://openid.net/mailman/listinfo/general



 
  



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


Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-11-30 Thread George Fletcher




+1

Avery Glasser wrote:

  Actually, this could be pretty simple to implement:
  
  
  Replace openid.aqe.preferred_auth_mode with the following:
  
  
   openid.aqe.auth_factor1
  Optional: The method of authentication the RP
would like the OP to perform, or in the case of a multi-factor
authentication, the first method that the RP would like the OP to
perform. The mode should match one of the advertised values in the
XRDS. If this is not specified, then any authentication method is
acceptable.
  Value: Comma-delimited list of "none",
"password", "pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"
  Note: The OP should attempt to authenticate
the user with the most secure mode requested. For example, if the OP
has determined that their voicebio method is stronger than their
password method and the RP requests either "voicebio or password", the
OP should strive to authenticate the user by "voicebio" when possible.
If the two modes are considered equally strong, then it is the choice
of the OP regarding which one or ones to authenticate against. OPs
should note that authenticating a user by a non-preferred method may
result in an RP denying access.
   openid.aqe.auth_factor2
  Optional: In the case of a multi-factor
authentication, the second method that the RP would like the OP to
perform. The mode should match one of the advertised values in the
XRDS. If this is not specified, then any authentication method is
acceptable. If this is not specified, it is assumed that the RP is
requesting only a single factor for authentication. The OP will not use
the same method for this factor as was used in any previous factors.
For example, if the first factor is a password, the second factor
cannot also be a password.
  Value: Comma-delimited list of "none",
"password", "pin", "fingerbio", "handbio", "hardotp", "irisbio",
"otherbio", "smartcard", "softotp", "voicebio"
  Note: The OP should attempt to authenticate
the user with the most secure mode requested. For example, if the OP
has determined that their voicebio method is stronger than their
password method and the RP requests either "voicebio or password", the
OP should strive to authenticate the user by "voicebio" when possible.
If the two modes are considered equally strong, then it is the choice
of the OP regarding which one or ones to authenticate against. OPs
should note that authenticating a user by a non-preferred method may
result in an RP denying access.
   openid.aqe.auth_factor3
  ... you can figure how it would continue.
There are very few use cases that would use more than two factors.
  
  
  So, in this case, if you want the user to
authenticate with two factors, first with a password and second with a
securID or voice biometric print...
  
  
  openid.aqe.auth_factor1 = "password"
  openid.aqe.auth_factor2 = "hardotp",
"voicebio"
  
  
  conversely, if you want two factors, which
could be any combination of password, hardotp or voicebio in any
combination:
  
  
  openid.aqe.auth_factor1 = "hardotp",
"voicebio", "password"
  openid.aqe.auth_factor2 = "hardotp",
"voicebio", "password"
  
  
  
  
  the response from the OP, assuming that it followed the request
from the RP would look like
  
  
  openid.aqe.auth_factor1 = "password"
  openid.aqe.auth_factor2 = "hardotp"
  
  
  I would think that this is clear enough that we could make the
small change to the spec to allow for this type of methodology.
  
  
  Thoughts?
  
  
  - Avery
  



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


Re: Making identities persistent?

2006-11-02 Thread George Fletcher




I believe it's possible to prevent impersonation for the use case where
the user instructs their IdP (OP) to inform the RP of the identifier
change.  However, this will only work
if the RP remembers the IdP that last authenticated that OpenID
identifier and only allows this message from that IdP.  

Thanks,
George

P.S. Functionally, this seems similar to the SAML ManageNameIDRequest
message.

Hallam-Baker, Phillip wrote:

  Don't forget that the a more important constraint here is to prevent impersonation.

I don't see how one can switch between genuinely autonamous IdPs in the way suggested without allowing a rogue IdP to impersonate anyone they chose.

At what point do the synchronization mechanisms you build in exceed the complexity of PKI?

  
  
-Original Message-
From: John Kemp [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 01, 2006 11:33 AM
To: Hallam-Baker, Phillip
Cc: Stefan Görling; Shutra Zhou; specs@openid.net
Subject: Re: Making identities persistent?

Hello,

I think you need the ability for a user to change his 
identifier at the RP (as George notes below) and also at the 
IdP. In addition, it should be possible for the IdP to 
providing OpenID "forwarding" if the user leaves for another 
IdP (perhaps the user will even pay for a forwarding
service?)

We're not talking about persistence as such (a particular 
users OpenID can surely change over time?), but more the 
ability for the user to update her OpenID when she switches 
from one IdP to another. At the IdP, this would I guess be 
kind of like leaving a forwarding address, as the user is 
"leaving" one IdP and moving to another. At the RP, the user 
is telling the RP that he is using a new IdP.

So, I think George's (1) is a necessity, and agree that (2) 
is a business decision, but certainly offers the ability for 
an IdP to be "community-friendly" if it so wishes, and may 
even be a good business decision.

Isn't this all about the likely /lack/ of persistence in a 
particular OpenID though?

Regards,

- John

Hallam-Baker, Phillip wrote:


  If we want identities to be persistent then we are going to need to 
introduce a layer of indirection.

This normally gets me worried about patents and such. Fortunately 
Multics did this, so did UNIX and VMS. Plenty of prior art.

If we are serious about decentralization then map the user 
  

identifier 


  onto a randomly assigned machine readable GUID.

  
  
-Original Message- From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Stefan Görling Sent:
Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc:
specs@openid.net Subject: Re: Making identities persistent?


The reasons for raising this question was partly that I've 

  

been doing 


  
some research on how people use e-mail addresses and sad 

  

to say, you 


  
can not expect the user to make wise choices. And even so, 

  

companies 


  
go broke even the best ones. Services comes and disappear. In my 
research over half of the population use non-portable e-mail 
addresses tied to an employer, university, etc.
and is likely to only live a few years.

E-mail is not a stable address/identity identifier. We 

  

must not rely 


  
on it as such.

If we want an identity to be persistent, it must contain a 

  

migration 


  
feature, so that I can move all their trust relations from 

  

one place 


  
to another. This of course creates a number of other 

  

issues such as 


  
security and complexibility, but it is my sincere belief that the 
issue should be addressed by the system and not only 

  

delegated to be 


  
dependent on wise user decisions.

Therefore, my +1 is on (1) below. I will try to read back 

  

on what has 


  
been said in the past on a 'change identifier' extension 

  

and see if 


  
there is anything I can do to help.

/Stefan



  Yes, this is important thing I thought. We should privide a
  

spec for


  the consumer to change their end user's OpenID URL,
  

optionally the end


  user can use multiple OpenIDs in this consuemr. And this
  

case can be


  expended as this, the IdP(OpenID Server) is closed down.

2006/10/31, George Fletcher [EMAIL PROTECTED]
  

mailto:[EMAIL PROTECTED]:


  This is a good use case and I think important for both us

Re: Making identities persistent?

2006-10-31 Thread George Fletcher




This is a good use case and I
think important for both users and IdPs (now OPs [OpenID Provider] per
the latest "editor's conference") to consider.

I see a number of options...

1. There has been some discussion regarding a "change identifier"
extension that would allow you to change your identifier at the relying
party. This would solve the use case and is necessary regardless of
the other options.

2. The OP (in this case AOL.com) could continue to provide an
"identifier management" page that would allow the user to specify the
OP of choice. This requires the OP to continue to serve the XRDS doc
or at least the indirection to a XRDS doc with the new OP. This is not
that much extra overhead for the OP, but it will likely be a business
decision as to whether to support such a feature.

3. The user gets to choose their OP so they can ensure that they don't
get "locked in". This is the ideal behind user-centric. However, in
practice, it will take good education and time for users to understand
the ramifications of their decisions.

Thanks,
George

Stefan Grling wrote:

  Hi everybody,

I'm trying to get a grip around your great work and have one issue that 
I'm not quite clear on, relevant to the discussion of using 
[EMAIL PROTECTED] identifiers, but also in a more general context. 
Please let me know if I've simply missunderstood my own question.

http://openid.net/specs/openid-authentication-2_0-09.html#anchor48 says:
"OpenID is decentralized. No central authority must approve or register 
Relying Parties or Identity Providers. An End User can freely choose 
which Identity Provider to use. They can preserve their Identifier if 
they switch Identity Providers."

Let us consider the case that I'm an AOL.com customer, and they act as 
an IdP providing we with an identifier. I use this identifier for 3 
years for identity management on most of the services I use, due to the 
huge success of the standard... However, I'm starting to get fed up with 
AOL and terminates my agreement with them. Is there any procedure for me 
to switch to another IdP? How is this done?

Best Regards,

Stefan Grling



___
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-10-22 Thread George Fletcher


Dick Hardt wrote:
 What is different with OpenID vs email is that there is certainty  
 that the user actually is the user. 
   
I'm a little confused.  How is there certainty that the user actually 
is the user?  The viability of the identifier representing the same 
user is dependent on the OpenID provider not recycling identifiers. Or 
did you just mean that in email, authentication is not always required 
for someone to use an email identifier?

Note that the OpenID protocol does not prevent idp.spammers.com from 
allowing any identifier to be used and authenticated regardless of 
whether it's the same user or not.  It is incumbent on the relying 
parties to determine if they will allow identifiers authenticated by a 
particular idp.

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


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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:

 On 20-Oct-06, at 10:14 AM, George Fletcher wrote:

 Of course, my expectation is that this syntax would be optional; the 
 user can always specify their full URI identifier.

 I agree that this kind of an identifier is not portable, but I'm 
 guessing that most users wouldn't know how to tweak their blog to add 
 the necessary OpenID 1.1 HTML code to change their IDP.  Most users, 
 just use flickr for photos and if flickr supported OpenID, could 
 potentially use some URI defined for them by flickr as an OpenID 
 identifier.  This identifier from flickr would not be very easily 
 portable.

 My understanding of the proposal from David was that this was a way to 
 discover the user's IdP, not that the email was an identifier.

 -- Dick

Sorry to imply that email should be a valid identifier.  That wasn't my 
intent.  I'm fine with where this discussion is headed (and has headed 
in the past; after reading the old threads).  For wide spread adoption 
it will be very important to have a If you're not sure what to enter, 
click here link on the login form to try and explain to users what they 
might be able to try as identifiers.

My comment was really trying to speak to the issue of identifier 
portability.  Is there an OpenID definition for this?

If I have an OpenID provided by SomeSite as http://george.somesite.com, 
then how is that identifier portable?  For it to be portable, 
somesite.com would have to allow me to either (a) change the HTML code 
of my public page (though if I read the draft 2.0 spec correctly, the 
HTML method is deprecated) or (b) provide some mechanism where I could 
change the IDP service URL returned in the XRDS document.  If 
somesite.com does not provide either of these mechanisms, then this 
identifier is not portable.  Also, the viability of my identifier may 
be dependent on the service. For instance, somesite.com may have a rule 
that says if I delete my SomeSite account, then they will no longer 
authenticate my identifier. Of course, user choice always enters in and 
I can choose to not use that service as my OpenID identifier provider.

The i-names infrastructure does solve some of this by focusing on the 
identity management issues.  Though here I'm paying explicitly for this 
portability service (along with others).

Thanks,
George

P.S. Should this discussion get moved to the general list?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:

 On 22-Oct-06, at 7:00 PM, George Fletcher wrote:



 Dick Hardt wrote:
 With OpenID, there is a presumption the user has selected a trust
 worthy IdP that  will only present the user's identifiers when it
 really is the user.

 Doesn't this imply that both the user and RP have to know which IdP's
 are trust worthy?

 It is a choice by the user. Just like the user chooses with ISP to 
 move their data, which browser to run, which OS to run. IN general, 
 those are not dictated by the RP.
I agree it is the user's choice to pick a trust worthy IDP.  However, 
if un-trust worthy IDPs exist, and users choose them, then the RP (in 
order to protect itself) has to determine which IDPs it considers trust 
worthy.  Hence both the user and the RP have to know which IDPs are 
trust worthy and which are not.

 Actually, idp.spammers.com cannot do that. The URL has metadata that
 states which IdP(s) are authoritative. What idp.spammers.com can do is
 flood an RP with a bunch of identifiers. But this is no different then
 a script creating new accounts on a system and is defended using the
 same mechanisms such as throttling and captchas.

 So why can't idp.spammers.com allow anyone to enter a URI of
 http://idp.spammers.com/name that resolves to a valid XRDS document.
 The RP then follows the IdP service link back to
 https://idp.spammers.com and does the association exchange.  Now the RP
 re-directs the user to https://idp.spammers.com for the login page,
 which just re-directs the user back to the RP with the valid assertion
 fields. idp.spammers.com does not have to ask the user for
 authentication credentials (that is out of scope for the spec).  For
 commenting on blogs this would be similar to bugmenot for web
 subscription services.

 So of course, the RP just needs to blacklist idp.spammers.com.  But
 now we are back in the same situation we have today where its a race
 between spammers setting up IdPs and RPs black-listing them.

 I don't understand why the RP needs to do that ... is the RP wanting 
 to do something it can't do today?
No, not really.  Though in most cases today the RP is also the IDP so 
relying on some other party to do the authentication doesn't happen 
too often (except within certain closely related services).  There is 
nothing stopping the RP from looking at the URI for the IDP and not 
accepting it as a valid IDP.


 Fundamentally, trust worthiness is paramount to making the system
 work.  For now, this means RPs will likely have some sort of ACL (black
 or white) for the IdPs that they deal with.

 The trust I am referring to is the user trusting the IdP to not 
 let someone else impersonate them.
I believe that there is also a need for the RP to trust the IdP to not 
allow impersonation.

 George: would you explain what problem you are wanting to solve so 
 that we can deal with a concrete example? There are use cases OpenID 
 solves today, and others require additional features that currently 
 are not in the specification.
A RP provides a personal finance service that allows users to manage 
portfolio information online.  It also supports online bill pay 
services.  This RP requires a set of information for the account to be 
created at the RP.  With the current specs that RP can accept the 
authenticated OpenID URI and request the additional required 
information.  Nothing different here. The issue come in the form of 
liability for the RP.  Is the RP liable if someone gets access to 
someone else's information?  In today's world this is the case partly 
because the RP is doing its own authentication.  If the RP is trusting 
an IDP to do the authentication (plain, strong, second factor, etc) then 
who is liable?  I suspect the RP is, though they might be able to go 
after the IdP.  Thus the RP needs to know which IdPs are trust worthy 
in order to protect its liability exposure.

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


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

2006-10-20 Thread George Fletcher




[Sorry for the strange
posting format. I got on the list after seeing
the emails. --George]

First, I'm new to the list and don't want to resurface an old and long
debated topic. 

To me this proposal is about how to make finding the
user's IDP simpler using something the customer is already familiar
with. Therefore, the email address format in not an
identifier, but rather a way to hint to the RP both my IDP and an
identifier to use at the IDP. The desire being to address current user
behavior which doesn't include specifying a URI as a login mechanism.
I don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft.
Trying to educate "the masses" to remember a new identifier, that for
some is meaningless (i.e. the user might not have a blog or other URL
that they are used to remembering or sharing), is difficult.

As another option, the RP could present UI that has a drop down of
"common IDPs" and
then based on the selected "common IDP" provide another text entry for
that IDP's form of identifer. However, that somewhat defeats the
purpose of trying to have a very simple form entry mechanism which
customers can get used to seeing and feel comfortable with. It also
places a burden on the RP to keep their UI up-to-date.

Of course, my
expectation is that this syntax would be optional; the user can always
specify their full URI identifier.

I agree that this kind of an identifier is not portable, but I'm
guessing that most users wouldn't know how to tweak their blog to add
the necessary OpenID 1.1 HTML code to change their IDP. Most users,
just use flickr for photos and if flickr supported OpenID, could
potentially use some URI defined for them by flickr as an OpenID
identifier. This identifier from flickr would not be very easily
portable.

Thanks,
George

  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.
* Reassignability: email addresses are not only reassignable, but for some
domains, they are notoriously short-lived identifiers.
* Non-portability: unless you own the top-level domain, they aren't
portable.

Food for thought...

=Drummond 

-Original Message-
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Recordon, David
Sent: Thursday, October 19, 2006 6:46 PM
To: specs at 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 "user at example.com" 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 "user at example.com" 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-10-20 Thread George Fletcher
It might create some confusion depending on the audience.  For the 
audience that doesn't run their own web server, or have their own blog, 
it might be confusing to enter a URI. 

This approach would help those users make the transition without 
restricting the users who do get it from entering URIs.  It also 
provides a simple way for RPs to appeal to a larger set of users (e.g. 
my mother-in-law wouldn't understand what to enter if asked for a URI 
based identifier).

Thanks,
George

P.S. Hopefully I've got Thunderbird sending plain text messages now so 
they don't get scrubbed in the archives.  Sorry about that.

Recordon, David wrote:
 Yes, potentially.  It is a bit of a hybrid approach I guess.

 --David 

 -Original Message-
 From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
 Sent: Friday, October 20, 2006 12:59 PM
 To: Recordon, David
 Cc: Drummond Reed; specs@openid.net
 Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style
 Identifiers

 # The thing is they aren't really giving them their email address.
 # Rather an identifier which looks like an email address to a user and #
 in some cases may also be an email address.

 Isn't that likely to create a lot of confusion?

 --
   Jonathan Daugherty
   JanRain, Inc.

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

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