Re: Check out my photos on Facebook
Sorry all. Something weird apparently happened with my FB account Please ignore. On Apr 8, 2009, at 18:29, Hans Granqvist invite+kna44...@facebookmail.com wrote: facebook Hans Granqvist has: 150 friends 7 photos 26 notes 18 wall posts 19 groups Check out my photos on Facebook Hi OpenID, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Hans To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=568401039k=42CTX456PZ4M5ADGYKX2YVr specs@openid.net was invited to join Facebook by Hans Granqvist. If you do not wish to receive this type of email from Facebook in the future, please click here to unsubscribe. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
I'm not sure what the new intellectual property policy means as regards to discussing on the mailing lists. Do I implicitly agree to this policy by posting ideas here? Can someone explain? More info at http://www.mail-archive.com/[EMAIL PROTECTED]/msg2.html Thanks, Hans On 2/1/08, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Figured I would ask if anyone is interested in brainstorming the next version of OpenID and how it can be used in Enterprise B2B settings and not solely focusing on consumerish interactions. Some things that I would like to see in the next version are: 1. A discussion on how AuthZ can converge with OpenID 2. Modeling of relationships 3. Not allowing an OpenID to be a vector for SQL Injection and putting something around what it should look like 4. A way to indicate to the relying party what level of authentication has occurred such as did the OP check a password, how did it validate a user. Without this, there is no way that a trust model could be established in a credible way. 5. A way for OpenID relying parties to filter out Ops. In a business scenario, if I run the Sun employee store, I may only want the Sun OP to talk with me. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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: Service Key Discovery 1.0
In essence, OpenID is a reaction to (perceived?) complexity, so it's an uphill battle to reference SAML, XRI, or anything that touches on any W3 or OASIS standard effort relating to XML and security, really. So for OpenID, there has to be a simpler, key/value-pair, way of doing what's desired, it seems. Hans On 1/21/08, Drummond Reed [EMAIL PROTECTED] wrote: Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
Interesting idea. Is there a way to do this via an RP- OP SSL handshake? Web apps typically don't have access to SSL private keys, at least in larger deployments. I wonder how your idea reduces network traffic, though. Don't you still have to retrieve the public key, which is likely larger than the associate message payload? I think hurdles against your idea are: 1. availability of public key cryptography in the RP libraries, and 2. fear that it's hard to correctly implement public key cryptography Hans On 1/21/08, NISHITANI Masaki [EMAIL PROTECTED] wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ 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: Adding fields to SREG (was: Re: SREG namespace URI rollback)
What are the few additional common fields? On 11/1/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 11/1/07, David Recordon [EMAIL PROTECTED] wrote: Sorry it took me a few days, but seems alright to me. I think a larger question would be if there should be any material differences with SREG 1.1 such as adding a few additional common fields. -1 on adding anything to SREG; that's what Attribute Exchange is for. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Hans Granqvist, CTO Phone: +1 (408) 569-3117 http://www.yubico.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
Interesting. I like that it's short and technically well written. So in practice a Client App would need to be able to distinguish the classes of OpenID identifiers, so it know when to do the OpenID authn call, right? Does that mean some existing systems may have clashing namespaces (for instance, maybe someone has a local user =hans somewhere, and all of a sudden it's being interpreted as an iname.) I guess the Client App can try multiple means and hide that from the user. In 4. Theory of Operation / Technical Overview you say The user is prompted for their verification key, which is typed into the supplied dialog box and submitted. --- I assume you mean supplied entry field or similar (for text apps)? Are you working on a PAM module for this? Thanks, Hans On 9/1/07, John Ehn [EMAIL PROTECTED] wrote: The Inline Authentication Extension attempts to solve the problem of legacy and interactive applications (Telnet/SSH) that are unable to launch a client Web Browser to perform an authentication request. http://extremeswank.com/openid_inline_auth.html This is done through the use of verification keys, which are provided either as needed by the OpenID Provider, or provided on a rotating basis from a hardware crypto device, or a key generating token (SecurID). As always, your comments are appreciated! Thank you, John Ehn ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Hans Granqvist CTO Phone: +1 (408) 524-1598 http://www.yubico.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Ping demoed OpenID technology at RSA. I hear Novell and IBM are looking at supporting OpenID. Microsoft has said they will in future products. Oracle and CA are following OpenID. So, yes. :-) I'm curious why almost all of these companies are non-existent on the mailing lists. Any insights? -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID.net Service Type Namespaces
I think it is a fallacy to embed too much meaning into a namespace URL. Encoding into a URL info like main, sub, and draft versions, plus add extension names and versions, and similar will soon end up with an ever-growing problem of trying to match compatible namespaces in the future. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Canonical list of overly general domains?
Daniel E. Renfer wrote: While I haven't been able to find a good list of domains that meet this requirement, what does everybody think of the idea that if you can't find a DNS entry for the domain part of the trust root then it's not a good candidate for a trust root. Maybe it's just my DNS servers, but I'm not getting a response for things such as com or co.uk any thoughts? The DNS lookup is interesting, but I feel a relying party should white-list the sites it accepts and only accept those. Any other mechanical trust relationships (such as generic blacklists) are likely to be worth next to nothing, so the RP might as well ignore checking for return address being in the trust root's set. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Drummond Reed wrote: I think you may have me mistaken for somebody else on the list (. . .) Double-blind anonymity in action? ;) -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
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. My assumption (which I am careful to not proclaim as truth) is that there won't be many IDPs around once the OpenID dust settles. Sure, there will be the run-in-the-basement ones, but for business-critical needs an IDP must spend a lot of money: maintain provable privacy of data, keep uptime, supply enriched services related to stored data, etc. Today's main internet companies can afford to invest in that, and they will also probably compete by adding OpenID access to their existing user base. Furthermore, many RPs will require a user to have an account with one or a few of these mega-IDPs. If there's money at stake, the RP would want to minimize risk. It's all about RP peace of mind. So few small IDPs will survive. Feel free to compare search engines and how a few big companies have all but obliterated the market. Hostile RPs are easy to handle. You just take your business elsewhere. But if an IDP decides to boot you when you're no longer indirectly promoting them using their identity URLs, you could stand to lose quite a lot. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
Marius Scurtescu wrote: On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. I think it's a good idea to say that the signed list MUST be generated by the IdP in that order. Then signature *verification* is compatible with OpenID 1's algorithm. Unless there is objection, I'll do this. Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Why would be an alphabetically sorted list better? I agree. What's the security benefit of forcing the protocol to use a specific order? The signed list has an inherent order that can change should attacks come to light in the future. Why remove that possibility? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
