Re[4]: [PROPOSAL] authentication age

2006-10-04 Thread Chris Drake
Hi Gabe,

Beautifully worded, and (IMHO) an extremely valuable real-world
opinion.  I too believe OpenID is currently a non-starter.  I have
dual vested interests:  I want OpenID to succeed, *especially* for RPs
like Visa, since my IdP makes money from supporting OpenID only when
OpenID ends up getting used.  I also believe that an IdP (and mine in
particular) is well suited for deploying secure technology (eg: two
factor tokens).  If, aside from making OpenID actually *work* for the
likes of Visa, we can build in the ability to provide a tangible
*benefit* to Visa from using it (that is: allow visa to REQUIRE that a
user has authenticate via two-factor means, to an accredited - i.e:
explicitly trusted by Visa - IdP) then we've not only cemented the
future of OpenID, we've gone an improved a pile of security problems
along the way.

Kind Regards,
Chris Drake
1id.com

Thursday, October 5, 2006, 1:41:34 PM, you wrote:

GW Chris-
GW As someone who has recently come from working in the financial
GW sector (Visa), its clear that OpenID is NOT intended for authentication
GW where the *relying party* cares about how the authentication is performed.

GW At places like Visa and for home banking, this means that OpenID,
GW without something more, is clearly a . These relying parties want
GW to know exactly how their users are being authenticated because their
GW business is all about risk management and creating business opportunities
GW around very good knowledge of the risk profile of each transaction type.

GW That all being said, I believe it should be possible to layer on
GW OpenID a form of IDP control such that a relying party can require a certain
GW class or group of IDPs be used when presenting authentication assertions to
GW them. The actual *policy* for how these IDPs are approved is probably
GW orthogonal to the protocol spec, but secure identification of those IDPs
GW (relative to some trust root, etc) could probably be made into an extension
GW usable for those parties who want it. 

GW My guess is that culturally, most people involved in OpenID have
GW *not* been interested in addressing these concerns. However, expectations
GW need to be better managed around these sort of relying-party cares
GW scenarios, because its not obvious without actually reading the specs
GW themselves...

GW -Gabe

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf
 Of Chris Drake
 Sent: Wednesday, October 04, 2006 8:26 PM
 To: Kevin Turner
 Cc: specs@openid.net
 Subject: Re[2]: [PROPOSAL] authentication age
 
 Hi Kevin,
 
 Sounds like you're leaning towards a root authority for IdPs who can
 audit procedures and verify protection in order to sign the IdP's
 keys?
 
 Joe blogger doesn't care much about identity assertions from an IdP,
 but it's a reasonable bet to expect that a Bank might care...
 
 Kind Regards,
 Chris Drake
 
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs



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


Adoption questions

2006-10-05 Thread Chris Drake
I still worry about end-user experience, privacy, and OpenID
usefulness to RPs running non-trivial services.

Can someone outline how user privacy gets maintained? (and what, if
anything, a user needs to do and/or understand to support this?)

Would any RP handling, say, credit-card data, be comfortable with
adopting the proposed spec?  Think: Amazon, wanting to re-authenticate
upon purchase.

Is my understanding accurate: OpenID is unable to support single sign
on.  If not - lets assume it's 9am.  I just signed on.  I can visit
RP#1 then RP#2 then RP#3 and go back and forth all day without
hindrance, until I next sign off - yes?

Privacy: during any hypothetical overheard lunchtime conversation
between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to
hear this fragment of conversation: ... yeah - that troublemaker is
one of our users too ... - or are they?

Sorry to harp on about the fundamentals.  I'm not so sure the
under-hood work is as important as the big picture, and I don't
think we've got this last bit right yet.

Kind Regards,
Chris Drake,
=1id.com


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


Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Chris Drake
Hi Martin,

This is getting very close to what I believe is the main important
thing we need in the spec to facilitate privacy, true SingleSignOn,
and to help avoid confusing users by getting them to key IdP URLs.

The only tweak I would like to see is right at the start, and is
implemented using OPTIONAL (at the RP) pure client-side stuff (plain
HTML or JavaScript).  The server-side tweak I'd like to see would be
this:

An ***IdP*** can *initiate* the OpenID login with the RP using
openid:Token.

How the User arrived at the RP with this token is not the concern of
the RP.  (could be javascript, browser plugins, participating IdP
helper CGIs, or even the RP itself).  The point is - the guts of the
authentication process remains unchanged and is backwards compatible,
but all the privacy-invasive components that live at the RP are thus
made *optional*.

Simple as that.  User only needs to remember and use one ID.  User
only needs to type it one time each day (or however long they elect to
stay logged on for).  Datamatching and privacy invasion are
eradicated.  No need to key custom IdP anonymity URLs ever.  Even
facilitates double-blind anonymous logins (with inclusion of a simple
RP nonce extension).  Win-win-win.

Kind Regards,
Chris Drake
=1id.com


Saturday, October 7, 2006, 2:49:17 AM, you wrote:

MA Dick Hardt wrote:
 I like making all identifiers work the same way. The wording around
 directed identity is somewhat confusing. Would be clearer if there
 was a complete description of what happened. ie. complete the  
 transaction. In Directed Identity, the RP needs to do discovery on
 the identifier provided to make sure the IdP is authoritative for it.
 

MA Perhaps I've misunderstood how directed identity works, but I figured
MA the flow would work as follows:

MA * The RP initiates Yadis discovery on http://anon.myidp.com/

MA * The IdP returns a document naming its authentication endpoint (in the
MA URI field) and a special anonymous token as openid:Token. openid:Token
MA may be the same as the public identifier from the previous step, but
MA this is not required.

MA * The RP initiates OpenID auth to the named endpoint using the openid:Token.

MA * The IdP notes that the special anonymous token has been used, but it
MA knows who the remote user is (via Cookies, for example) so it can 
MA generate an identifier and remember that it belongs to that user/RP combo.

MA * IdP responds to RP with the generated public identifier (which *is*
MA publically resolvable, of course.)

MA * RP resolves the IdP-provided public identifier, where the IdP will
MA provide for Yadis discovery and specify that it is authoritative for
MA that URL.

MA * We're done.

MA The important thing is that, just as I've separated the public 
MA identifier from the IdP token (or handle, if you like), this separation
MA also applies to the IdP-generated public identifier.

MA (sorry that this is a bit rough. I've not really spent the necessary
MA amount of time preparing the above and I'm in a hurry, so if there are
MA spots where I'm not clear I apologise and I'll clarify later! :) )

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



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


Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Chris Drake


CHRIS DRAKE'S PROPOSED FLOW

1) User *enters* UPI, but a Discovery Agent intercepts this: UPI does
   *not* get posted to RP
2) Discovery Agent sends UPI to IdP
3) IdP authenticates against UPI
4) IdP selects appropriate RP-specific IPI
5) IdP initiates authentication with RP using IPI


Kind Regards,
Chris Drake,
=1id.com



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


Re[2]: [PROPOSAL] bare response / bare request

2006-10-06 Thread Chris Drake
KT On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
 Let me play the dumb customer here and say:
 
 * A whole lot of real-world users would love OpenID-enabled bookmarks.
 * A whole lot of websites would love to offer them.
 * A whole lot of IdPs would love to provide them.

KT Okay Customer, if both websites and IdPs would love it, is it okay if
KT it's something that websites + IdPs can layer on top of the core?  If
KT some sites chose not to, and the IdP said login bookmark not available
KT for this site, would that be okay?

Technically - the only thing we need is a mechanism for the IdP to
find the RPs OpenID bookmark entrance - a hidden field in the
original login FORM should be sufficient: IdP can then save this URL
in the users profile for them.

Chris.

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


Re[2]: Consolidated Delegate Proposal

2006-10-11 Thread Chris Drake

 Martin wrote:
 I'm surprised that our resident privacy advocates aren't making a
 bigger
 deal out of this. (If the privacy advocates have no problem then I'll
 let this go, since this isn't a use case I feel particularly strongly
 about myself.)

Dick wrote:

I was supportive of keeping the delegate from the IdP until I  
realized that the delegation was public knowledge and could not be  
hidden from the IdP.

Wednesday, October 11, 2006, 4:42:35 AM, Drummond wrote:
DR The same argument convinced me, too. If public XRDS documents are what we're
DR using to provide user control of identifier synonyms and thus provide
DR identifier portability -- which is the clearest and cleanest approach we've
DR seen -- then the best thing we can do from a privacy perspective is not
DR mislead users that they are protecting their privacy by using a public
DR OpenID identifier and a private identifier with their IdP.
DR =Drummond

This is backwards:  Users have already chosen the IdP whom they trust
to look after their identity and privacy:  and except for the unlikely
double-blind scenarios, no user will want to hide RP info and usage
from their own IdP.

The privacy violations come into effect when the *RP* is given access
to any more information than it strictly needs to know to accomplish
its task.

Might I suggest a fast-track approach to tabling the core requirements
for OpenID 2.0 and bypassing the debate: lets just identify exactly
what everyone wants to achieve, make sure the proposed protocol can
support everything everyone wants to do - then leave it up to the RPs
and IdP's as to which features they feel like supporting.

Nobody knows in advance whether privacy or delegation or any other
feature is going to succeed in the marketplace, so I feel it's better
to accommodate it, then let the market decide.

The bottom line is that we're spending months arguing over what will
end up to be a few days work and a couple of hundred lines of code.

The only thing I want to see, which can then be used to accommodate
privacy protection, is for RP's to accept an IdP-initiated login.
It's none of the RPs business how my user selected their
openid.identity for presentation to the RP.

Chris.

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


Re[2]: [PROPOSAL] request nonce and name

2006-10-13 Thread Chris Drake
Hi All,

Just so everyone remembers:  GET encoded http://; URLs usually
appear en-mass in public lists (from proxy cache logs).  If you don't
want to POST data anyplace, remember to expect replay attacks
often. 

Kind Regards,
Chris Drake


Friday, October 13, 2006, 7:48:31 PM, you wrote:

JH On 10/13/06, Martin Atkins [EMAIL PROTECTED] wrote:
  True, even one single pass through parameter should do.

 This causes the minor inconvenience that the RP will probably now have
 to implement its own parsing, rather than using the framework's
 pre-supplied functions for dealing with urlencoded query strings.

 Not a major deal, but I'd guess that this is where the idea to use
 return_to args came from in the first place.

JH return_to arguments can only be trusted if they are taken from the
JH signed return_to parameter, which means parsing the signed return_to
JH parameter anyway. So it's at least no worse.

JH It's better in that the parameters do not now appear twice in the
JH response (once double-encoded)

JH Example of a response with parameter in the return_to:

JH 
http://a.url/?drink=0xC0FFEE%21openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521;...

JH Example of a response with hypothetical openid.appdata field:

JH 
http://a.url/?openid.appdata=drink%3D0xC0FFEE%21openid.return_to=http%3A//a.url/;...

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



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


Re[2]: Identifier portability: the fundamental issue

2006-10-14 Thread Chris Drake
Hi Josh,

 I do not believe the RP needs to know the IdP-specific identifier ever
 (worse: I think it should never be allowed to know it, or even be
 allowed to see it!).

JH Why not?

PRIVACY.  Page back and read trough my posts to this list for the
intricate details.


JH Where is power being granted to the RP? It has pretty much none.
JH It *does* have responsibility, but only as much as is necessary to
JH make the protocol work.

If RPs are allowed to build up linked portfolios of everyones
identifiers, they can get together with other RPs (or sniff IDs in
google) to snoop on and conspire against our users behind their backs.
If the true spirit of OpenID is to empower users, it's seriously
neglectful to block users from protecting their own privacy.

 Can we not adopt my earlier suggestion: just ensure OpenID can permit
 IdP-initiated logins.  This permits every scenario of portability (and
 privacy) that everyone wants, without us having to continue to debate
 it ?

JH Huh? How is IdP-initiated login related to privacy or portability?

It is ** NONE OF THE RPs BUSINESS ** how the OpenID that got presented
to it was originally selected by, or resolved for, our Users.  Letting
the IdP initiate a login allows the IdP to PRIVATELY negotiate with
the user over which identity to present (which for anyone who cares
about privacy, will usually be a per-site identity not linked to their
main OpenID or vanity domain or whathaveyou.).

The beauty of this suggestion is that we don't even need to debate it:
so long as IdP initiated logins are supported, market forces will then
decide whether or not privacy and security become widespread in
OpenID.

I'm not saying this should be the *only* way an OpenID login can take
place - just that if this simple concept is implemented, that we can
then defer all privacy issues to the IdPs in future, and concentrate
now on getting this spec out the door.

--

I notice the current spec:
http://openid.net/specs/openid-authentication-2_0-10.html
does not even *mention* privacy? (besides the allusion in the
abstract: It does this without the Relying Party needing access to
password, email address, or other sensitive information. - but
somehow nobody's understanding that the users OpenID *itself* is
sensitive information, especially in the way google will in future
let anyone troll back through our users online tracks using this
ID...)

Also missing are

16.  Security Considerations

and

16.1.  Preventing Attacks

Perhaps someone should add a section on privacy, and someone should
take a crack at the security aspects!  Who is in charge of writing
this stuff?  I've submitted 102 (one hundred and two!!!) security
considerations in the posts I've made to this list so far:  Shouldn't
someone be documenting this?

Chris.

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


Re[2]: Discussion: RP Yadis URL?

2006-10-15 Thread Chris Drake
Hi Drummond,

Don't forget we'll need some way for an IdP to discover the return_to
URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
LINK tag in the web page that the RP displays for accepting a login,
so an IdP (or browser plugin agent!) can discover this by parsing
the referrer page directly.  There's a lot of anti-phishing work
taking place right now: such a scheme would allow OpenID instant
access to these new standards too.)

Kind Regards,
Chris Drake


Monday, October 16, 2006, 2:59:12 AM, you wrote:

DR +1. All of the defined algorithms for obtaining the XRDS document from
DR either a URL or XRI will be going into Working Draft 11 of XRI Resolution
DR 2.0 starting this week. So it seems all the OpenID Authentication 2.0 spec
DR needs to specify is that they work against the return_to URL.

DR =Drummond 

DR -Original Message-
DR From: [EMAIL PROTECTED]
DR [mailto:[EMAIL PROTECTED] On Behalf
DR Of Johannes Ernst
DR Sent: Sunday, October 15, 2006 12:00 AM
DR To: specs@openid.net
DR Subject: Re: Discussion: RP Yadis URL?

DR Yes. Or any of the other defined algorithms for obtaining the XRDS
DR file, given the return_to URL.

DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:

 I assume you are referring to the return_to URL?

 Current libraries add all kinds of parameters to that URL, would  
 you be suggesting that the IdP does a GET on the return_to URL with
 content-type of XRDS?

 If so, then we should add that to the spec. I'd then like to get  
 clear on what would need to be in the Yadis file for indicating the
 login_url.

 -- Dick

 On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular  
 Yadis discovery on it. (Likely, all of the RP's URLs point to the
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the  
 location of
 the RP's Yadis document?

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

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




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

DR Johannes Ernst
DR NetMesh Inc.


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



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


Re[4]: Discussion: RP Yadis URL?

2006-10-15 Thread Chris Drake
Hi Dick,

1. IdP's advertising a list of sites that accept OpenID - like the
   way PayPal list stores that accept their currency I guess.  It's
   annoying to a user to have to come back to the place they just
   clicked in order to click a second time in order to go where they
   wanted to in the first place...  Better to send them where they
   want when they click the first time...

2. Privacy and delegation: if we force the user to initially interact
   with the RP, this gives the RP the opportunity to profile our
   users, start collecting (and sharing with other RPs) correlating
   information about them, and otherwise destroys IdP ability to
   protect user privacy.

Basically - this comes back to your Discussion: bookmark login url
discovery message - and for the sake of additionally supporting
future security enhancements (eg: anti-phishing), I'd recommend we
place something inside the RP's login FORM page, like a META or
LINK tag, for browser agents to use, or IdPs to find via referrer
URLs.

Kind Regards,
Chris Drake


Monday, October 16, 2006, 3:36:53 AM, you wrote:

DH Hi Chris

DH Would you clarify these IdP initiated scenarios?

DH I envisioned that an IdP learned of an RP from the user have an  
DH initial interaction with the RP. The IdP would then save the RP URL
DH for later use in case the user wanted to go back to the RP directly
DH from the IdP.

DH -- Dick

DH On 15-Oct-06, at 10:30 AM, Chris Drake wrote:

 Hi Drummond,

 Don't forget we'll need some way for an IdP to discover the return_to
 URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
 LINK tag in the web page that the RP displays for accepting a login,
 so an IdP (or browser plugin agent!) can discover this by parsing
 the referrer page directly.  There's a lot of anti-phishing work
 taking place right now: such a scheme would allow OpenID instant
 access to these new standards too.)

 Kind Regards,
 Chris Drake


 Monday, October 16, 2006, 2:59:12 AM, you wrote:

 DR +1. All of the defined algorithms for obtaining the XRDS  
 document from
 DR either a URL or XRI will be going into Working Draft 11 of XRI
 Resolution
 DR 2.0 starting this week. So it seems all the OpenID  
 Authentication 2.0 spec
 DR needs to specify is that they work against the return_to URL.

 DR =Drummond

 DR -Original Message-
 DR From: [EMAIL PROTECTED]
 DR [mailto:[EMAIL PROTECTED] On Behalf
 DR Of Johannes Ernst
 DR Sent: Sunday, October 15, 2006 12:00 AM
 DR To: specs@openid.net
 DR Subject: Re: Discussion: RP Yadis URL?

 DR Yes. Or any of the other defined algorithms for obtaining the XRDS
 DR file, given the return_to URL.

 DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:

 I assume you are referring to the return_to URL?

 Current libraries add all kinds of parameters to that URL, would
 you be suggesting that the IdP does a GET on the return_to URL with
 content-type of XRDS?

 If so, then we should add that to the spec. I'd then like to get
 clear on what would need to be in the Yadis file for indicating the
 login_url.

 -- Dick

 On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular
 Yadis discovery on it. (Likely, all of the RP's URLs point to the
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything  
 about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the
 location of
 the RP's Yadis document?

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

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




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

 DR Johannes Ernst
 DR NetMesh Inc.


 DR ___
 DR specs mailing list
 DR specs@openid.net
 DR 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: Summarizing Where We're At

2006-10-15 Thread Chris Drake
Hi David,

What is the rush for?  There's a lot of unhappy people here due to
missing protocol elements.

I for one believe the lack of privacy considerations is an entire
OpenID killer.

Is there a reason why you've omitted my IdP-initiated login proposal
from your short list (also known as bookmark login url discovery)?

If you're not convinced of the importance of privacy - read your own
IdP home page: http://pip.verisignlabs.com/

  Verify your identity without compromising your privacy with PIP,
   the personal identity management system from VeriSign. 

Verisign chose Privacy as *the* most important and critical feature
that their IdP should support - does your PIP service plan to *use*
OpenID, and if so, how do you propose to handle privacy problems (eg:
RP's collaborating about users behind their backs) ?

Imposing an arbitrary time limit will result in an incomplete spec.

Kind Regards,
Chris Drake


Monday, October 16, 2006, 5:28:52 AM, you wrote:

RD So previously I had set the goal of the final draft coming out last
RD Friday, though we've missed that.  I'm resetting this bar to Wednesday
RD which means we need to wrap up discussion on proposals where there is
RD general consensus as well as accept that some proposals will not make it
RD into this version.  For all proposals, unless there is general consensus
RD they should be included by Tuesday evening they will not be included.

RD * Request Nonce and Name
RD  - Has been partially implemented, openid.nonce -
RD openid.response_nonce, no agreement on the need of a request nonce
RD specifically, rather discussion has evolved into allowing a RP to pass
RD appdata like in Yahoo's BBAuth.  No formal proposal on the table yet,
RD thus will not be included in this version.

RD * Authentication Age
RD  - Re-proposed today adding clarity in motivation, general consensus is
RD needed to add to specification.

RD * Remove setup_url
RD  - Little discussion and no general consensus to do so.  Rather seems
RD asking for feedback from checkid_immediate implementers on the parameter
RD would be beneficial at this time.

RD * Consolidated Delegation Proposal
RD  - Very active discussion, the only proposal I'm willing to stall the
RD spec for.  Seems very important a strong conceptual model is created at
RD this time.

RD * Change Default session_type
RD  - Proposed, no discussion yet.

RD * Bare Request
RD  - Proposed, no discussion yet.

RD I also feel strongly that no new proposals, except to update existing
RD ones, should be considered for inclusion in this version.

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



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


Re[2]: Identifier portability: the fundamental issue

2006-10-16 Thread Chris Drake
Hi Drummond,

DR ... if there is any record at all of any association between these
DR two identities, ...

double-blind anonymous authentication solves this problem.  The RP
knows nothing more about you besides:
A) you're authenticated, and/or
B) you've been here before (eg: have signed up for an account)
The IdP knows merely
C) That you wanted to log in somewhere

The RP does not know your ID or even your IdP, and your IdP does not
know what site you logged in to.

I have a working proof-of-concept that I demonstrated to a few people
some months back, let me know if you've not seen it, and I'll send
over the URL

In a nutshell - this relies on uniform nonce formats and asymmetric
cryptography (so the RP and IdP can talk between one another without
making any actual contact - the browser and/or user carry the
authentication payloads forth and back without referrer URLs or any
other info that can link the 2 sites (RP/IdP) together).

Besides all that - the normal use case for an IdP in OpenID world
(remember: decentralized) will be someone running some open-source
code on their own server, so trust in this instance *is* boolean: at
least in so far as if there's anything for someone to not be
trustworthy about themselves for - it won't be the fault of their IdP
code PROVIDING their IdP has provided them with IdP-initiated logins
in order to allow this user to protect their own privacy in the first
place.

Court orders are what I termed 3.5. Authorized exploitation in my
threat list, and insider leaks I called 1.3.6. physical attack of
server resources (eg: server/hosting-facility compromise) - there's
another 98 other threats to keep in mind here as well:-
http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Procedures_and_Data.html

While your example might seem extreme, the consequences are also
extreme (or fatal, if you live someplace like China) - which is why I
take privacy so seriously.  Stick Himalayas video into google news
if you want to watch what Chinese do to their own people when found
trying to visit the Dalai Lama.  Now - how comfortable are you with
the idea of letting 1.5 billion Chinese people use OpenID without
making it easy to help them protect their own privacy ?

There's a big picture here, and it's not about meeting some arbitrary
deadline or saving a day or two of coding work - it's about producing
something that works, and can be deployed ethically.

Take a long hard look at that Nun lying dead in the snow, then tell me
you still believe there's no need for IdP-initiated privacy protection
in OpenID.

Kind Regards,
Chris Drake,
=1id.com


Tuesday, October 17, 2006, 7:29:00 AM, you wrote:

DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute
DR it to you?

DR =Drummond 

DR -Original Message-
DR From: [EMAIL PROTECTED]
DR [mailto:[EMAIL PROTECTED] On Behalf
DR Of Martin Atkins
DR Sent: Monday, October 16, 2006 12:25 PM
DR To: specs@openid.net
DR Subject: Re: Identifier portability: the fundamental issue

DR Chris Drake wrote:
 
 There seem to be a lot of people on this list who want to hate and
 loathe the IdP, and grant all power to the RP.  I do not understand
 this reasoning:  our users will select the IdP they trust and like,
 then they will be using a multitude of possibly hostile RPs
 thereafter: the reverse is simply not true.
 

DR If I'm using one IdP to assert my primary public identity, they can
DR hypothetically develop quite a profile about me. I probably don't mind
DR too much in most cases, because I researched them and found that they
DR are a good provider and won't sell my data out to the bad guys.

DR However, there might be some things I want to do (for example, posting
DR locally-prohibited speech on a public forum) that I don't want attached
DR in any way, shape or form to my public identity. The trust relationship
DR I have with that IdP probably isn't enough for this; if there is any
DR record at all of any association between these two identities, as 
DR friendly as my IdP may be, there is a chance that it will be ceased by
DR court order, or leaked by an insider, which might lead to me getting in
DR serious legal trouble.

DR This is just one (perhaps extreme) example of why my trust in my IdP is
DR not universal and all-encompassing. Trust is not a boolean.


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



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


Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support

2006-10-18 Thread Chris Drake
Hi Scott,

All solutions for client-based MITM and phishing prevention can easily
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.

We can then leave these people to build their tools and protection
howsoever they like, safe in the knowledge that when it's *done*,
there will be a range of new plugins that will immediately work with
all OpenID 2.0 enabled sites - and best of all - it does not have to
hold up the OpenID 2.0 development in the meantime.

The only thing we need to give to these tools is a way to get the
login process started - that is - OpenIDHTTPAuth: the downloaded
plugin needs to be able to get an entry point for the OpenID CGI code
on the web site.

---

Here is a copy of my vote to include the above proposal, which
contains more info abut it too:


Hi,

Why's this proposal depreciated ?
( http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my vote here:

+1 to [PROPOSAL] bare response / bare request

Besides the listed uses, it also allows IdPs to layer privacy and
delegation easily on top of OpenID, as well as permitting cool future
features (like letting a user change something at their IdP, and have
that change be pushed out to all relevant RPs).

This is a small and simple to implement hook which I believe will be
the dominating bit of OpenID protocol use in future.

Alternatively - if we can standardize a way for the OpenIDHTTPAuth
proposed extension to discover the RP's OpenID entry point [so as to
reliably eliminate the optional first step proposed here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good
working alterative way to accommodate the bare response part that we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL
   that's somehow available to scripts, plugins,
   software agents that encounter OpenID login
   pages.

   Suggestion: (for OpenID-enabled login pages):-

  link rel=openid.httpauth href=http://my.rp.com/openid/blah.cgi;

---


Kind Regards,
Chris Drake


Thursday, October 19, 2006, 6:07:08 AM:

 It is vulnerable to a man in the middle attack - the RP, instead of
 redirecting to the IdP redirects to itself or some other site in
 cahoots, then proxies the conversation between the user and the IdP
 thereby compromising the users (global) credentials as they pass through.

SK Right, we've known about this for quite some time unfortunately there hasn't
SK be a particularly easy solution to it and I classify this as one of those
SK The Internet Sucks problems.  I'm not saying we shouldn't/couldn't do
SK anything about it I just think the right solution that mixes
SK ease-of-implementation and user need hasn't been found yet.
 
 There really needs to be user-agent support to avoid that - either
 something CardSpace like, or browser plugin that only ever presents a
 pre-authenticated user.

SK I think we're headed in this direction.  However, we have to crawl before we
SK can walk.  At least solving a big chunk of the use cases, getting some
SK momentum behind the platform and solving a specific problem for users
SK *today* is better than trying to build the perfect tool.  We can talk and
SK talk on these lists but we really don't know how users are going to use this
SK stuff (or abuse it for that matter) until its out there and working in the
SK wild.

SK I can't emphasize more the fact that with every passing day that we don't
SK have OpenID v2.0 out the door, we're losing momentum from fixing specific
SK user problems that are solved in the existing specification.

SK - Scott

SK ___
SK general mailing list
SK [EMAIL PROTECTED]
SK http://openid.net/mailman/listinfo/general



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


Re[2]: Server-to-server channel

2007-04-04 Thread Chris Drake
Hi All,

Since it's a lot easier to just put a server-to-server mechanism in
place, than it is to argue about what it should be used for - can we
perhaps instead attempt to agree that server-to-server is going to be
something potentially useful in at least some cases, and go ahead and
specify it?

I believe there is a good use case for my OP (that I have chosen to
trust as the gatekeeper to all my personal information) being allowed
to store my data, arbitrate (server-to-server) access to it, and
propagate (server-to-server) updates.  This isn't complicated - HTTPS
transport over existing endpoints is sufficient.

Wednesday, April 4, 2007, 9:06:49 AM, Anders Feder wrote:
... Currently, if my OP turns rogue or otherwise fail to serve me...

The idea that OP's might turn hostile, and that RP's are more
trustworthy seems completely backwards to me.  When I choose an OP (or
I download and run my own), I'll take trust, reputation, and safety
into account.  When I choose all my RP's, I'll essentially ignore
trust, reputation, and safety because I've already chosen my OP to
handle all this for me.  It's also safer to trust one OP, than it is
to trust (for example) all 100 RPs I've used.  And that's not even
*starting* on the fact that I can change my OP away from any rogue one
any time I want anyhow...

I can understand that folks involved with RPs and associated
development will be horrified at the idea of giving their users
control of their information.  If I was an RP, I would not like to let
my customers revoke my access to their details: I'm going to want my
hypothetical RP to spam them indefinitely, continue to charge their
credit card long after they've gone, sell their details to marketing
companies, count them as active users when I try to sell my RP to
google, provide their address to snail-mail campaigners or police,
send unsolicited text messages to their mobile phones, plunder their
data to retaliate against them when I find them saying nasty things
about my RP in public, and so forth. 

Every now and then, some RPs might even violate user trust and
secretly store user OP-Only information without permission: the RP
will be easily named and shamed when they're found out - which they
will easily be, as soon as a user revokes access and then (for
example) discovers the RP still sent them spam.

Here's some things I want to do, but that OpenID does not currently
support - but could with server-to-server support:

1. 1-click, or zero-click Single-Sign-On (no typing)

2. Single-Sign-Off

3. User-Centricity (This is in quotes because I define this as
   Giving ME full control of MY information)
   A) propagating changes to my info out to RPs
   B) revoking access to my info at RPs
   C) auditing the usage of my info by RPs
   D) access authorization ( SAML+X-GTRBAC / XACML )
  eg: facilitating grants by 3rd parties allowing users to access
  RP facilities (eg: data that RP cannot physically store)
   E) identity protection
   
4. Other: I'm not the only one who's looking to implement facilities
   that require more than just a browser-transported, user-present
   OpenID interaction.

All server-to-server comms will be properly secured and authenticated
(ie: no old/rogue/non-authorative OP will be able to influence any RP)

Kind Regards,
Chris Drake



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


Re[2]: Server-to-server channel

2007-04-04 Thread Chris Drake
Hi Martin,

You wrote
MA The age of the information needs to be taken into account here.

When the information (rightly) lives at the OP instead of the RP, none
of that age complexity exists.

It's *my* name. It's *my* credit card. If any RP wants this info, make
them come to me (my OP) and get it. Let me say no. Let me know each
time they ask. But most importantly, let me (my OP) provide the
correct, updated info each time the RP wants it.

Kind Regards,
Chris Drake


Wednesday, April 4, 2007, 5:45:55 PM, you wrote:

MA Anders Feder wrote:
 
 Imagine an RP requesting your bank account number X from your OP. Time
 goes by, and your OP goes out of business. Later, you switch banks and
 your account number X is assigned to someone else. In the meantime, the
 RP has been preparing a payment for a job you have done for them. The RP
 look up your account number in its database, and see X. And since the RP
 has not received any updates to your bank account information, it 
 reasons that your account number is still X and consequently disburse
 your payment on a stranger's account ...
 

MA information is old, then the RP would presumably be hesitant to act on
MA it without verification.

MA What constitutes old information depends on the attribute... things
MA like Full Name are, for many people, changed never or at most once in
MA their lives. However, things like a credit card number tend to change
MA every few years as cards expire.

MA Some information has a built-in expiry date (such as credit card 
MA details), while other information just has a likelyhood of change.
MA This implies to me that the following three things are needed:

MA   * The possibility of a hard expiry date on a particular piece of
MA information.
MA   * soft expiry dates which are more like refresh this every n 
MA months, where the RP gets less and less convinced about the accuracy of
MA the data as it ages, but may continue to use it for some time even when
MA it's a bit old.
MA   * The ability for an RP to request a refresh of attributes it stores
MA without necessarily including the user in the transaction. (The user
MA presumably will have made approval/revoking decisions out of band at an
MA earlier time.)



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



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


Re[2]: Server-to-server channel

2007-04-04 Thread Chris Drake
Thursday, April 5, 2007, 3:50:49 AM, Martin wrote:

MA Chris Drake wrote:
 Hi Martin,
 
 You wrote
 MA The age of the information needs to be taken into account here.
 
 When the information (rightly) lives at the OP instead of the RP, none
 of that age complexity exists.
 
 It's *my* name. It's *my* credit card. If any RP wants this info, make
 them come to me (my OP) and get it. Let me say no. Let me know each
 time they ask. But most importantly, let me (my OP) provide the
 correct, updated info each time the RP wants it.
 

MA I think you're kidding yourself if you believe that RP's won't cache the
MA information they obtain.

True - we may not always be able to force some RPs to not violate our trust.

This is not, in my opinion, a justification for preventing any IP from
acting in a trustworthy way, and definitely not a justification to
deny users the opportunity (by omitting the mechanism from the
protocol) to select RPs who claim not to cache information.

MA For some things it's legitimate: they need to store your name because
MA otherwise they'd need to talk to your OP (via you!) every time they
MA render a page containing something attributed to you.

OK - yes - I concede that some data age complexity does probably
creep back in if RPs choose to deny users the opportunity to audit the
use of user information.  (If I've got a choice between 2 RPs, and RP1
renders pages with my name in it, without giving me control over that,
while RP2 makes repeated calls to my OP every time it occurs: I'll
always choose to use RP2 - because it's the only one of the 2 options
that's user centric, and gives me the ability to control the use of
my information.

Yes - this could be a tough drain on RP and OP resources.  Tough.

MA they need to store your name because
MA otherwise they'd need to talk to your OP (via you!)
via you! is not a correct statement.  This is a server-to-server
topic: we're discussing a data flow that is by your explicit prior
permission, but that takes place when you are not necessarily
present. 

MA For other things it's more dubious than that, but the fact that it
MA is technically possible means that at least some RP's will do it.
MA I think it'd be a mistake to write the spec under the assumption
MA that they won't unless we're going to include something that
MA prevents it. 

I do not follow your logic.  It looks like you're saying there is an
opportunity for some RP's to act badly, therefore we should not even
try to code user-protection into the protocol

By all means - include preventative code (and for some kinds of
attributes, digital time-stamped and signed assersions about the
attributes solve these problems).  But I think it's a far bigger
mistake to completely leave out a server-to-server channel altogether.

When a rogue RP violates your trust and caches data without your
permission, that's bad.

When you choose not to specify a server-to-server channel, you're
forcing *every* RP to behave in exactly the way that your theoretical
rouge RP might have done.

What's a bigger mistake?  Having a few bad apples, or having no apples
at all?

Chris.

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


Re[2]: Server-to-server channel

2007-04-04 Thread Chris Drake
Thursday, April 5, 2007, 5:43:02 AM, you wrote:

[snip]

DO How these keys are handled internally could be left to the
DO consumer or RP.

[snip]

This sounds like another *strong* use-case for updating the OpenID
protocol to allow transactions to take place when the user is not
present.

I am not likely to be present when people relying upon my certificates
choose to verify signatures, check for revocation, or attempt to
encrypt stuff destined for me.

There needs to be a way for the RP to contact my OP and get access to
my information (eg: my current public key and revocation list) - by my
explicit prior consent of course. 

I believe it's entirely unreasonable, and privacy-invasive, and
identity-theft-dangering, to expect every RP out there to have to
cache a copy of all my credentials, and for me or my OP to have to
propagate any changes/updates/addition etc out to them all.  Keeping
all my info in one place solves this - only if the RPs can get what
they want, *when* they want, which can't be done without
server-to-server means.

Chris.

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


Re[3]: Server-to-server channel

2007-04-05 Thread Chris Drake
Hi Martin,

Yes - sorry - I accidentally hit reply instead of reply all. I
later did re-post to the list though.  For the benefit of the list,
your reply is at the end here.

Re-reading my reply, I think my wording sounded pretty strong, and I
might not have made it clear that I'm not pushing for 100% of data to
live at the OP: rather - I want to give the user a choice in the
matter (that is - after all - the entire spirit of user-centric). I
want users to have the *option* to decide whether to sign up to RP#A
or RP#B, and be able to base their decision upon the data-handling and
protection practices of the RP.  Some RP's will want to store
everything just like they do today.  Some will want to embrace user
centricity and give their customers full control, and most will
probably tread a line somewhere inbetween.

As long as we build something that supports all this, then we can
leave it up to the normal market forces to steer the Identity future
the way they want - with the key issue (for us) being that OpenID has
the chance to persist in this future.  Right now - OpenID is right at
the bottom of the pile, being almost the worst Identity 2.0 protocol
currently on the market.  IMHO - this is a problem that's easily
fixed.

I wrote:
 Yes - this could be a tough drain on RP and OP resources.  Tough.
You wrote:
MA You can't just wash your hands of this problem because it doesn't suit
MA your rather bizarre idea about how the world should be. Sites need to be

I contest that I *am* allowed to wash my hands at this point,
because it is absolutely my problem: I operate an OP, and I'm involved
in helping RPs accomplish Web 2.0 goals.  I'm smack in the middle of
all the consequences that flow from allowing users to control their
own data howsoever they wish. 

I further contest that the idea of me being in control of my own
information about me is not bizarre.  It might not be how anything on
the web works today - true - but I'm pretty confident this is
something most people do, or will, want.

Imagine you're at the newsagent buying a magazine.  You hand over
your credit card, and the shopkeeper says No problem - I'm happy to
sell you your goods, but I need you to first agree to let me make a
photocopy of your credit card, grab you name and email address, and 
keep it in all on our files for the next 10 years.  Oh - and we'll
need to be sending you the occasional marketing message from time to
time over those 10 years as well.

Now *that* is something that almost everyone will agree is bizarre.

Imagine, instead, the exact same thing occurs on a web site, instead
of at a newsagent.  Nobody even blinks when this gross misuse of *my*
information actually does occur.  I would go as far as to say that
opinions contrary to mine about how the world (internet) should be
are in fact the bizarre ones!! 

---

My suggestion for how an OP might choose to present the kinds of
data-protection defaults users might want would be for the OP to have
a set of per-user global account preferences.  Mum and Dad users can
click the convenient radiobutton.  Political activists can click the
strong protection radiobutton.  Folks inbetween can be given
middle-road defaults, and/or anyone can be given per-use overrides.
Whichever OPs (or OP software packages that you choose to download
and run yourself) that do these things the best, should then quite
quickly become the market leaders.  As long as the protocol supports
the protection, the market can innovatively offer it.

The challenges I see at present, are these:

1. How should an RP advertise to an OP what it's server-to-server
   endpoint is.

2. How should an OP advertise to an RP the same thing.

3. How should an RP indicate to user-agents (eg: browser plugins like
   SSO enablers, secure chrome/anti-phishing/anti-virus addons,
   form-fillers, OP helpers [or even OP software itself, if running on
   an end-users home machine]) that it is an OpenID 2.0 enabled
   service in the first place.  I've pushed for this to be
   standardized and enforced, because it offers the absolute strongest
   future support for new technologies - and I do so again now.  If my
   web browser, upon visiting www.example.com, can immediately detect
   that it's an OpenID 2.0 site (eg: through a link tag on every
   page, or the root or base URL, or HTTP headers, or whatever) - a
   massive pile of cool opportunities all spring up to make Web 2.0
   *seriously* more compelling, useful, and protective for everyone.

   Heck - Cardspace already did this - so we don't even have to argue
   the merits:  They learned the long, hard, and painful way that
   excluding the user agent seriously undermines the trust and
   usefulness of Identity management.
   
Kind Regards,
Chris Drake


Thursday, April 5, 2007, 5:14:58 PM, you wrote:

MA Not sure if you deliberately took this off-list, but I'll reply directly
MA and let you divert it back to list if you want. :)

MA Chris Drake wrote:
 
 MA For some things it's

Re[2]: Specifying identifier recycling

2007-06-06 Thread Chris Drake
Hi,

OpenPGP keys can be resolved using key servers - for example -
here's mine:

http://pgp.mit.edu:11371/pks/lookup?search=0xc0ded00dop=vindexexact=on

In the old days, they used key ID to find these things, but they
stopped doing that and started using fingerprints when people like me
worked out how pick our own key ID's :-)

I don't think public keys for identifiers are a good idea.  I know
you're all sick of me whining about privacy, but once again - these
things leak all kinds of information about the victim... err.. owner
so if you start using them in places they were not meant to go, for
things they were not meant to do - you're begging for trouble.

Oh yeah - and don't forget that all signed keys expire every year,
most keys (whether or not signed) expire every few years, and you
can't ever get a key without it coming inside a certificate, and these
things can change all the time.  Not my ideal concept of anything
that's supposed to be persistent.

Oh - and the obvious thing while I'm here - nobody's got public keys
anyhow, with the exception of a few geeks here and there, and everyone
involved in cybercrime.

Kind Regards,
Chris Drake,
=1id.com


Wednesday, June 6, 2007, 2:50:17 PM, you wrote:

dr For posterity, here's how I'd summarize this thread about using public keys
dr as persistent identifiers:

dr 1) Yes, a public key could be used as an identifier, and could serve as a
dr persistent identifier if it was not reassignable.

dr 2) The issue of it becoming invalid as a credential if the private key was
dr compromised is orthogonal to its use purely as an identifier, i.e., as
dr Johannes points out, if the private key was compromised, use of the public
dr key could revert to the role of serving purely as an identifier, and another
dr set of credentials (such as another public/private key pair) could be
dr assigned.

dr 3) In this light, the primary drawbacks I see to public keys as identifiers
dr are:

dr a) They are typically much larger than other persistent identifiers
dr designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or
dr Handles as issued by CNRI).
dr b) I am not aware of a resolution protocol designed for them, with
dr the exception that I believe syntactially they could be used as XRI
dr i-numbers.

dr =Drummond 

dr -Original Message-
dr From: [EMAIL PROTECTED]
dr [mailto:[EMAIL PROTECTED] On Behalf
dr Of Johannes Ernst
dr Sent: Tuesday, June 05, 2007 7:27 PM
dr To: =nat
dr Cc: 'OpenID specs list'
dr Subject: Re: Specifying identifier recycling

dr I think you are making an invalid analogy. What prevents you from
dr setting up a private key reset function the same way you set up a
dr password reset function, using an alternate credential? You allow
dr for this for non-public-key credentials but not for others ...

dr But I don't want to perpetuate this thread given the general  
dr reluctance of the community to think about public key cryptography at
dr this time ... I just want to go on record that I find the arguments
dr made counter public keys on this thread non-persuasive and want to
dr pick it back up when the community is ready to go there ... (note
dr also that the security industry would not exist in the shape it does
dr if we didn't have public key crypto, so that technology does  
dr contribute something somewhere ... perhaps also to OpenID?)

dr Just follow the following argument ... let's assume that the problem
dr that started this thread
dr ... can be solved by adding a number to the URL identifier (using a
dr fragment syntax or an i-number or whatever other approaches were  
dr discussed)
dr ... then it also can be solved by adding a large number instead of
dr just any number
dr ... then it also can be solved by adding a large number that could be
dr a public key, which is nothing but a large number
dr ... which, therefore, makes a public-key-based approach at least as
dr powerful as a plain number

dr Just some stuff for thought ... ;-)

dr Cheers,



dr Johannes.


dr On Jun 5, 2007, at 17:58, =nat wrote:

 Hi.

 Ok. Now I see the heart of the topic :-)

 Fundamental difference is that you postulate that one cannot lose  
 one's
 credential including all the information that bears onto establish
 one's
 identity while I do not postulate so.

 For example, one can loose one's password and reset it.
 You can loose your credit card and replace it.
 Doing so has not nullished your identity. You still are yourself.
 Your identity itself and the attribute associated with it apart  
 from this
 particular lost credential data (whether it was a password or  
 credit card)
 stays intact.

 This picture changes dramatically when you use public key
 as your main identity address. If you lose your private key,
 that's the end of story. Your relationships with all the RPs are  
 ruined.

 That is why I believe that we should not be using this kind of  
 public key
 as the identification data for RPs.

 Also, mandating OPs to specify a unique

Re[2]: [Idschemas] identity schema element metadata: using existingspecifications

2007-09-08 Thread Chris Drake
Hi,

Having missed the summit - can anyone tell if there was any dissent or
scaremongering going on?  The idea of assisting everyone who's
collecting information about me, to share it easily, seems like an
exceptionally Bad Idea (tm).

If anyone's building anything that assists these companies to give
up or relinquish their collection of my data, in favor of letting me
hold the one single master copy if it myself, on my chosen IdP, and to
let me arbitrate who can use it, when, and how - now *that* would be
something to congratulate people about.

Search google/google-news for paper shredder ...

Kind Regards,
Chris Drake,
=1id.com


Saturday, September 8, 2007, 5:33:20 PM, you wrote:

DR Mark,

DR I just wanted to say that based on what I learned about them at the Data
DR Sharing Summit (http://datasharingsummit.com) today, and what I read on my
DR first pass tonight, these are fine pieces of work that really push the ball
DR forward.

DR Hats off to you.

DR =Drummond 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:idschemas-
 [EMAIL PROTECTED] On Behalf Of Mark Wahl
 Sent: Thursday, September 06, 2007 6:05 PM
 To: ID Schemas
 Cc: OpenID specs list
 Subject: [Idschemas] identity schema element metadata: using
 existingspecifications
 
 
 I'm reformatting the table of identity schema metadata, located at
 http://idschemas.idcommons.net/moin.cgi/MetaData, into a
 pair of more compact and usable specifications. One spec describes
 where the existing well-known metadata (e.g., Dublin Core) should be
 used when describing identity schemas and their schema elements (i.e.,
 attribute types and claim types).  The other spec will describe how
 to represent identity schema metadata for which there is no
 pre-existing well-known specification.  I've attached a copy of
 the first draft of the Identity Schema Element Metadata: Using
 Existing Specifications.
 
 Mark Wahl
 Informed Control Inc.
 


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



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


Re[2]: [osis-general] OSIS PAPE call results

2007-11-08 Thread Chris Drake
Hi,

A quick comment:

  ... End User does not provide shared secrets to a party potentially
   under the control of the Relying Party ... 

So if the secret gets provided to any third party - so long as it's
not a party under control of the RP - it's *not* phishing ?

I think what everyone's trying to say is that Phishing-Resistant
means End Users can't be tricked into giving things to the wrong
place... is all the jargon/terminology/verbosity really necessary in
the definition?

Kind Regards,
Chris Drake


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


Re[2]: OpenID Email Discovery

2008-01-05 Thread Chris Drake
Hi Phillip,

I wasn't aware that DNSSEC existed yet (outside a few obscure European
TLDs?).  Since you appear to work for Verisign, and I'd like to set
this up - can you please send me a URL when I can obtain a signed
DNSSEC certificate for my .COM domain ?

Kind Regards,
Chris Drake


Saturday, January 5, 2008, 6:18:14 AM, you wrote:

HBP You can use domain validated SSL certificates or DNSSEC here. Either is 
sufficient.

HBP There is no technology gap here.  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Artur Bergman
 Sent: Friday, January 04, 2008 6:14 AM
 To: Trevor Johns
 Cc: 'OpenID specs list'
 Subject: Re: OpenID Email Discovery
 
 
 On Jan 4, 2008, at 12:07 PM, Trevor Johns wrote:
 
  On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote:
 
  Fair or not, I am tired of hearing how un-secure DNS, when 
 everything 
  we do is based on it, and it being the worlds largest working 
  distributed database.
 
  There's a difference between working and secure. For example, email
  works great but it's far from secure.
 
 
 Whatever, this discussion is old and bores me. You can always go out
 and use DNSSEC.
 
  There is SSL connecting to the provider that is being refereed  
  from the srv/txt field. Which is no different than what you are
  referenced to from an A or CNAME or MX
 
  Which is why I said it depends on what is used as the claimed  
  identifier. If the user's email address is used as the claimed  
  identifier and I am able to change the user's record from:
 
 example.com   TXT   ‘OpenID * 10 https://*.example.com/’
 
  to:
 
 example.com   TXT   ‘OpenID * 10 https://*.myevilsite.com/’
 
  then all the SSL in the world won't help.
 
  If the email address _isn't_ the claimed identifier, then the end
  user has to validate that their OP-local identifier (which they  
  don't know) is displayed correctly by the service provider. 
 This is  
  worse than an SSL failure, there isn't even a dialog asking 
 them to  
  click OK!
 
  Not that it matters anyway, since people just click OK.
 
 
  If a service provider detects an SSL failure, there's no person  
  there to press okay. Their server will just summarily deny the  
  authentication request.
 
  The click OK problem is only between client-server 
 communication.  
  This is server-server communication.
 
 Isn't this just a lookup of email address - openid/url that is then
 handled as a normal openid login?
 
 Artur
 
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs
 
HBP ___
HBP specs mailing list
HBP specs@openid.net
HBP http://openid.net/mailman/listinfo/specs



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


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

2008-04-02 Thread Chris Drake
Hi Drummond,

I pushed hard for RP identification for 2 or 3 months back around
October 2006.  If anyone wants to go back through the archives,
there's a pile of other important reasons to have some way that an IdP
and/or browser agent can identify an OpenID-enabled site.  The antique
thread below lists a few.  My proposal too was a link tag.

Kind Regards,
Chris Drake


Tuesday, November 7, 2006, 12:51:15 I, you wrote:

CD Hi Johannes,

CD I proposed a solution to the single sign out problem a month or two
CD ago.

CD In fact - a whole range of solutions have been proposed, and relative
CD merits of all discussed already - does anyone have the free time to go
CD back over the postings, extract all the knowledge  contributions, and
CD document them all?

CD To summarize my proposal - I was seeking a standardized OpenID RP
CD endpoint interface into which I (as an IdP) or a software agent (eg: a
CD browser plugin) could post user information - be this a login
CD request, email change request, log-out request, account signup,
CD account cancelation, or whatever.  My preferred implementation was a
CD LINK tag placed on (and thus identifying) a login page, and within
CD the link tag, the endpoint of the RP for accepting IdP(OP/agent)
CD input.

CD Kind Regards,
CD Chris Drake


CD Tuesday, November 7, 2006, 1:04:44 PM, you wrote:

JE I continue to believe that we need single-sign-out
JE functionality, in particular once OpenID moves up the stack for
JE higher-value transactions.


JE Some people have made the case that that is undesirable
JE and/or impossible; I beg to differ.


JE Having automatic authentication against the IdP is quite
JE similar to not having a password on the identity at all, in that
JE it reduces the confidence that we know the real-world identity of
JE the entity/user at the other end. In my view, there's nothing
JE wrong with that, but we do need to be able to convey that to
JE relying parties in a way that cannot be easily attacked.





JE On Nov 6, 2006, at 16:41, Joshua Viney wrote:

JE One question re: User Experience and single-sign-on comes to mind:


JE How do we treat users who are accessing their IdP and
JE Relying Parties via public computers?


JE Use Case:
JE Good User at public library wants to leave a comment on Blog X
JE Blog X requires the person to authenticate via OpenID
JE Good User enters their OpenID and successfully authenticates
JE via email and password (or whatever) (and authorizes the RP
JE ('realm' in 2.0) if necessary) at their IdP
JE Good User is redirected to Blog X signed in
JE Good User leaves comment
JE Good User signs out of Blog X (if sign out is even an option)
JE Good User then leaves the public library and goes shopping
JE Evil User jumps on computer and proceeds to leave comments at
JE any number of OpenID enabled blogs using Good User's OpenID (he
JE saw it while looking over Good User's shoulder, or he checks any
JE sites that Good User did NOT sign out of that might display his
JE OpenID)
JE Evil User, uses Good User's signed in IdP session to sign into any number 
of sites, etc


JE Outcome: Good User's reputation is ruined and his/her OpenID
JE is banned from a whole list of Relying Parties. Good User then
JE blames their IdP, the Relying Parties and OpenID as a technology
JE and tells everyone he/she knows not to use it blogs about it and
JE initiates a press release.


JE It may be easy to pass this off as an implementation specific
JE issue or as user error, but this use case is somewhat likely for
JE 2 reasons:


JE 1. A user's OpenID URI is not necessarily a private thing
JE (obscurity is not security anyway)
JE 2. Users will be at least 1 site removed from their IdP while
JE accessing a Relying Party, and no one is use to signing out twice
JE 3. It is very very likely that IdP's will use some type of remember me 
functionality


JE One solution to consider would be a global sign-out feature
JE on relying party sites that signs users out of their IdP as well.
JE Another solution would be to make very specific recommendations
JE about messaging users who may be using public computers.






JE Josh Viney
JE http://www.eastmedia.com -- EastMedia
JE http://identity.eastmedia.com -- OpenID, Identity 2.0








JE ___
JE user-experience mailing list
JE [EMAIL PROTECTED]
JE http://openid.net/mailman/listinfo/user-experience










Kind Regards,
Chris Drake,
=1id.com


Thursday, April 3, 2008, 4:38:13 AM, you 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