IGF: CARML
Anyone here noodling how to integrate the emerging OASIS CARML/AAPML specifications into OpenID? 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
RE: OpenID Security
-Original Message- From: Peter Watkins [mailto:pet...@tux.org] Sent: Friday, February 06, 2009 8:29 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID Security What do you mean, the implementation? There is no the implementation. Are you arguing that for the OpenID *protocol* to succeed, every *implementation* has to be secure? That sounds like a marketing problem to me, and it's one you solve by having math/crypto experts ensure the *protocol* is good. Period. When someone finds a bug in Postfix, we don't say SMTP is broken and run away from email; we say Postfix version such-and- such is broken, Wietse fixes it, and we go on. Sometimes, the implementation is busted where a consumer (albeit a technical one) can tell the library and version. SMTP makes it easy by responding to HELO. Is there an OpenID equivalent? Likewise, the protocol can be defined as weak where someone may apply additive security on top of it. Kinda like doing SMTP over TLS and/or S/MIME. A relay can have additional logic to determine how to respond to insecure interactions. At times, the SMTP protocol has morphed without breaking backward compatibility. I suppose you could argue for protocol compliance tools as part of protecting the OpenID image -- at least that might allow OpenID proponents to disown any insecure library that happened to fail the protocol tests. But I wouldn't expect too much from that, either. Automated testing is good for finding obvious problems, but it's no replacement for good, smart programming, and not a cure for bad code. I'd feel more comfortable with software that passed some long-running fuzzing tests, but you really don't want to be vouching for the security of specific implementations. That's just asking for trouble. The way that you achieve protocol compliance can be done through complex and public interoperability demonstrations (Think Burton Group times two), basic automated test harnesses (Think Java/J2EE compatibility testkit) and review by disinterested parties. -Peter 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
OpenID Security
Darren, I would challenge you by saying the following: 1. In the same sense that it is unreasonable for OpenID to satisfy every identity use case on the planet, you also shouldn't expect a static analysis toolkit to do the same either. 2. Which is worse, having to sort through false positives or to not perform static analysis at all and have OpenID fail once some bad guy busts the implementation so badly that everyone runs away from OpenID? 3. A small correction on OWASP. OWASP DOES perform analysis on OPEN SOURCE implementations at no cost. If you have a commercial version, then you need to pay. The open source implementations simply need to submit their code to http://owasp.fortify.com to get the process started. 4. The link above is merely hosted by Fortify and they provide the tools. The actual execution of scanning isn't even done by Fortify employees but other members of the OWASP community. 5. FYI, I am the project leader for several OWASP projects and am the chapter leader for Hartford (one of the largest). Our next meeting is on Tuesday at 5pm Eastern where we will have Mary Ruddy of Higgins presenting. Our meetings are free to attend and for this one, we will also be webcasting it. The webinar information will be sent out on Monday to the mailing list. Subscribe at: http://lists.owasp.org/mailman/listinfo/owasp-hartford If you would like to attend in person, here is the information: http://www.owasp.org/index.php/Hartford 6. Engaging a reputable third party isn't a bad idea but keep in mind that part of their assessment will use the same automated tools. Firms I like include Security Compass (http://www.securitycompass.com) Artec (http://www.artecgroup.net) and Cigital (http://www.cigital.com) Date: Thu, 5 Feb 2009 15:48:06 -0500 From: Darren Bounds dbou...@gmail.com Subject: Re: OpenID Security To: McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com Cc: specs@openid.net Message-ID: 26563eca0902051248o446aa21br23aeb19f743ae...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 I do not believe OWASP presently does any active vulnerability analysis. Rather they provide definition around best practices and reference material around web application security as well as a small set of open source vulnerability analysis and penetration testing tools. With regard to the Fortify link you sent previously; in my experience thus far, I have not found a single automated vulnerability analysis tool that's worth the price tag or the effort involved in tuning it. More often than not they find nothing more than low hanging fruit and false positives. Even worse, they often miss ore than they catch, resulting in a large number of false negatives. Subsequently any 'certification' an automated tool can provide should be taken with a grain of salt. IMO, if a formal security assessment is desirable, it would be much more fruitful to engage a reputable 3rd party to perform one manually. Darren 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
OpenID Security
If your implementation is 100% open source, then you don't have to worry about licensing as OWASP (http://www.owasp.org) will scan at no cost... -- Message: 1 Date: Fri, 6 Feb 2009 01:34:33 +0900 From: Nat Sakimura sakim...@gmail.com Subject: Re: OpenID Security To: McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com Cc: specs@openid.net Message-ID: bf26e2340902050834ybf1ae5ara6b97aaac28cd...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Yeah. Fortify is nice. I do not know what would be the licensing terms now, but before, it used to have a traveling kind of license that allowed consultants to do the evaluation for the projects of their customers. It might be worthwhile for somebody like OIDF to buy a license and run a certification program out of it. Of course, having secure profile, which we do not have yet, is a prerequisite though. =nat On Wed, Feb 4, 2009 at 11:48 PM, McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com wrote: OpenID certainly has security features but are all the libraries out there written to secure coding practices? Wouldn't it be great if all the library creators could have their code reviewed for security defects? Check out http://owasp.fortify.com/ 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs End of specs Digest, Vol 30, Issue 7 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
OpenID Security
OpenID certainly has security features but are all the libraries out there written to secure coding practices? Wouldn't it be great if all the library creators could have their code reviewed for security defects? Check out http://owasp.fortify.com/ 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
RE: PC Insurance Carriers
I would think the membership of Japan in PC would be a different audience than in the US. Maybe we should keep the conversations separate but leverage the same playbook. I do hope that the vendors on this forum would encourage their PC insurance customers to participate as well... From: Nat Sakimura [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:40 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: PC Insurance Carriers That sounds interesting. We have some member companies from PC insurance in OpenID Japan as well, so I might able to cordinate something with you. =nat On Fri, Dec 5, 2008 at 4:31 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I am attempting to put together a discussion amongst employees of PC insurance carriers to discuss scenarios for using OpenID for independent insurance agents. Does anyone on this list know of employees at carriers that have an understanding at a technical level regarding OpenID? NOTE: I am not interested in turning this into a vendor lead generation mechanism. 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ 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
PC Insurance Carriers
I am attempting to put together a discussion amongst employees of PC insurance carriers to discuss scenarios for using OpenID for independent insurance agents. Does anyone on this list know of employees at carriers that have an understanding at a technical level regarding OpenID? NOTE: I am not interested in turning this into a vendor lead generation mechanism. 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
OWASP Certification
Figured I would ask a somewhat offtopic question to see if anyone has thoughts. I am currently project leader for OWASP Certification Project (http://www.owasp.org/index.php/Category:OWASP_Certification_Project) which has on its roadmap, certification questions around identity. What types of things about OpenID in specific or identity in general should be covered? Post any thoughts you have here: https://lists.owasp.org/mailman/listinfo/owasp-cert * 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
Using email address as OpenID identifier
This would require defining an OpenID SRV record in DNS. Would make sense for someone to get this formally defined as part of IETF. Could kinda be done in the same way that Boeing is moving forward definition of XRI in LDAP.. -Original Message- Message: 1 Date: Mon, 07 Apr 2008 18:56:57 +0100 From: Martin Atkins [EMAIL PROTECTED] Subject: Re: Using email address as OpenID identifier To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Paul E. Jones wrote: Perhaps it is important to say, though, that I do not think it requires the e-mail providers to get on board with this (in my view) simpler notation. I could use an ID like [EMAIL PROTECTED] and that should work, if myopenid.com would publish the appropriate NAPTR record. I could also insert NAPTR records into the packetizer.com DNS server that would allow me to use my email address, but point at my preferred OpenID provider. In short, just because the [EMAIL PROTECTED] syntax is used does not mean that it necessarily an e-mail address: it could be, but more importantly, it just follows that familiar format documented in RFC 822. Funnily enough, I've always percieved the fact that syntactically-valid but non-existant email addresses are being used as identifiers as a problem rather than a benefit: * It creates confusion for users when something looks like an email address but it doesn't behave as one. I've seen this sort of confusion with Jabber servers, where users get confused that their Jabber ID and email address are not the same, especially when Jabber clients say For example, [EMAIL PROTECTED] under the Jabber ID field. * If not all email-shaped OpenID identifiers are actually working mailboxes, it's likely to lead to a distressing user experience where the user is first asked to enter their OpenID identifier -- that is, their email address -- and then they're asked to enter and verify their email address. At this point, I expect users to at best say Stupid computer! Remember what I've told you! and at worst get confused and think that the OpenID identifier they entered was not correct. * As has often been raised in both the OpenID-with-email and in the Jabber circles, many people are reluctant to give up their email addresses to the public eye for fear of spam. Note that Yahoo.com will, by default, use a big opaque string as an identifier rather than the user's Yahoo! account name for this very reason. * 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
OpenID and Yahoo
Does anyone have a perspective on Yahoo and AOL and their weak support for OpenID? It is good that they are a provider, but shouldn't they really also allow access based on an OpenID issued by signon.com, myvidoop.com and others... * 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
OWASP Review
Is there merit in having a third-party group such as OWASP (http://www.owasp.org) provide a third-party opinion that is public on the security of OpenID? Having large entities market OpenID will help spread the word even faster. * 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
RE: OpenID 3.0
The answer of whether an insurance agency would be the OP is it depends. Generally speaking, there are very large insurance agencies and brokers such as Marsh, BBT that have 40K employees where they would probably stand up their own OP where as the small agency with three people none of which are IT wouldn't be. In many domains, whether it is insurance agent, travel agent, etc they may also use an application service provider (ASP) to host much of their core business systems. At some level, it would make sense for these types of providers to become OP. Generally speaking, insurance agents can do business with a multitude of carriers where the OP would need to assert things such as agent X is licensed to sell auto insurance in Texas and life insurance in California which don't fit the typical name/value pair structure and feels more XACML like. -Original Message- From: Paul Madsen [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:23 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 in a B2B case, would not the insurance agency be the OP, and its identity carried through the relevant assertion fields? As Masaki-san points out, the RP can base its authorization decision on any number of factors - some of which might be carried through OpenID, some not. In this sense, OpenID is already 'converged' with authorization, as an RP already bases its authz decision on the asserted identifier. Allowing for the protocol to carry other attributes that might also feed into the decision is just an enhancement. Theoretically possible would be for the OP assertion to actually carry an 'authorization statement' expressing some set of privileges the user should enjoy at the RP (and that the RP would respect). Possible, but weird because of the implied loss of sovereignty for the RP. paul McGovern, James F (HTSC, IT) wrote: If you were going to use OpenID in a B2B scenario where an insurance agent want to access an insurance carriers web site, the identity provider would need to not only pass the identity of the agent but also the insurance agency, the insurance agent is employed by. -Original Message- From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F 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 ** *** 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
RE: OpenID 3.0
If you were going to use OpenID in a B2B scenario where an insurance agent want to access an insurance carriers web site, the identity provider would need to not only pass the identity of the agent but also the insurance agency, the insurance agent is employed by. -Original Message- From: NISHITANI Masaki [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: OpenID 3.0 Let me confirm a point. On #1, do you mean to enforce OpenID to control the identity-holders are permitted to access what kind of content or service on RP or provide some kind of help making RP's decision easier? I feel it is natural for RP to do access-control be itself, but on the other hand, any information which describes what kind of person the accessing web-user is, will be welcome for RPs such as gender, age or any kind of attributes. McGovern, James F 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 * 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
OWASP
I would be curious to know if the implementers of the various OpenID libraries have used tools such as Ounce Labs (www.ouncelabs.com), Coverity (www.coverity.com) and others to ensure that the OWASP Top Ten (www.owasp.org) doesn't occur? * 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
RE: Login Federation
Many OpenID providers allow a user to display the activity of their credentials. Is it possible that others may want to more strongly specify what is displayed for this scenario or as usual, leave it optional. One of the more interesting usage scenarios is when you visit a site such as PIBB and specify an OpenID from Signon.com which allows you to authenticate to them via CardSpace. So at some level, signing on to multiple sites could occur using multiple protocols. Likewise, I would think that for automatic signon, it would be a good thing if the OpenID provider could tell the relying party how long to leave an otherwise idle session open before timing it out. Not sure if this would require an extension or not. -Original Message- From: Brett Carter [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 10:09 PM To: McGovern, James F (HTSC, IT) Subject: Re: Login Federation I don't think so. The implementation I'm thinking of would allow the user to decide what sites would be logged into automatically. Really, it's just amounting to automatically typing in the user's url on their chosen sites. We could even delegate login requests, preserving the decentralized nature of open id. -Brett On Fri, 15 Feb 2008 12:53 pm, McGovern, James F (HTSC, IT) wrote: Wouldn't this take the user out of the middle? I would think this would be bad at some level. -- Message: 1 Date: Thu, 14 Feb 2008 19:31:40 -0800 From: Brett Carter [EMAIL PROTECTED] Subject: Login Federation To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes I've dug around a bit, and haven't found anything, so I thought I'd ask here. Is any work being done on adding some sort of federated login for open id? By 'federated' I simply mean that signing into my open id provider, this automatically signs me into all my open id enabled sites (of my choice) at once. I have a few ideas I'd like to kick around if somebody isn't already working on this. If so, please feel free to point me in the right direction. -Brett --bacarter * 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
Login Federation
Wouldn't this take the user out of the middle? I would think this would be bad at some level. -- Message: 1 Date: Thu, 14 Feb 2008 19:31:40 -0800 From: Brett Carter [EMAIL PROTECTED] Subject: Login Federation To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes I've dug around a bit, and haven't found anything, so I thought I'd ask here. Is any work being done on adding some sort of federated login for open id? By 'federated' I simply mean that signing into my open id provider, this automatically signs me into all my open id enabled sites (of my choice) at once. I have a few ideas I'd like to kick around if somebody isn't already working on this. If so, please feel free to point me in the right direction. -Brett -- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs End of specs Digest, Vol 18, Issue 8 * 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
RE: OpenID 3.0
I'm not sure what there would be to say in the spec about this: SQL injection is not party of the standard, but rather a feature of some implementations :) [JFM] I agree that many of the ways that have been implemented to date are insecure and that many of the implementors would be well served by running their code bases through tools such as Ouncelabs (www.ouncelabs.com) Coverity (www.coverity.com) and others. I also believe that if the spec further defined what an identifier could look like, implementors could write validation code to make more secure. If an identifier can be anything then you can't really strongly validate. The provider authentication policy extension handles half of this already (telling you what checking the OP did). It does not cover the trust issue though, so without a pre-existing trust relationship there is no reason to believe the PAP assertions. The trust side is something that would be interesting to see addressed in future specs. [JFM] Strongly agree here. OpenID needs to be used for more than just blog sites and free email providers. If businesses who conduct commerce in a B2B scenario were to embrace, the notion of trust needs to be discussed. Likewise, it seems as if many folks here are either consultants or software vendors and having a strong enterprise story could put money into your pockets. This is already possible with OpenID 2.0: 1. make the Sun OP provide an OP identifier URL that can be used to initiate a directed identity request to authenticate any user of the OP. 2. to authenticate, the Sun employee store would initiate an OpenID request against the URL from (1) rather than asking the user to enter an identity URL. With this setup, the user need not know that they are using OpenID or know what their identity URL is. [JFM] I think the scenario I mentioned was an example and not meant to be 1 to 1. Maybe you could tell me how it would work if I had more than one Sun, say Oracle, IBM, BEA and CA. * 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
OpenID 3.0
If it turns out that some particular feature absolutely can't be done without making a new Authentication spec release then so be it, but ideally I think we want 2.0 to be stable for many years to come to avoid repeating all of the current pain of incompatible versions and the poor user experience that creates. This is noble to think this way but the odds of this becoming reality are very slim. There are always new attack vectors and this protocol needs to change to stay secure even if it breaks backward compatibility. I think the issue of whitelisting not only belongs on the side of the relying party but also allowing each user of OpenID to indicate whitelists in terms of how they will want their OpenID leveraged. This should be supported by the identity provider. This is more than simply putting the user in the middle. One of the scenarios that reputation would need to consider is the security of all channels. For example, in my role I may deem that I will only trust interactions that occurred 100% over SSL. If someone specified an HTTP Open ID (e.g. http://james.myopenid.com/) and not (https://james.moresecureopenid.com) then I can ignore the entire flow. Reputation works only if there are certain trust cues of which things such as EV SSL could be one. As far as the LDAP thread, has anyone approached Microsoft regarding turning Active Directory into an OpenID provider? * 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
OpenID 3.0
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
Integration with Enterprise Directory Services
Is there merit in also defining other aspects such as how the OP would store history in LDAP by defining new ObjectClass? * 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
RE: Integration with Enterprise Directory Services
We should do whatever it takes to make OpenID successful within an enterprise setting and not exclusively focus on consumerish usage scenarios. I would think that folks from Sun and other large ISPs would also leverage directory services. Likewise for those providing OpenID libraries, you software should work in enterprise settings while minimizing configuration regardless of how easy it is. -Original Message- From: Schleiff, Marty [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 8:17 PM To: Johannes Ernst; specs@openid.net Cc: McGovern, James F (HTSC, IT); Drummond Reed Subject: RE: Integration with Enterprise Directory Services The process to get an OID issued under the directory OID includes doing an RFC. The old draft (haven't touched it for about a year) can be seen at various URLs. Here's one: http://opends.org/source/xref/trunk/www/public/standards/draft-schleiff- ldap-xri.txt [EMAIL PROTECTED]; CISSP Associate Technical Fellow - Cyber Identity Specialist Information Security - Technical Controls (206) 679-5933 * 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
RE: Integration with Enterprise Directory Services
For CardSpace, MS and other providers store it in the SeeAlso attribute. Figured OpenID in the next rev of the spec should talk more about implementation details. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 11:57 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Integration with Enterprise Directory Services James, are you asking about the recommended format for saving an OpenID identifier in an LDAP directory? If so, I know Boeing has done some work in that area -- I can check with their directory guru. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Wednesday, January 23, 2008 1:47 PM To: specs@openid.net Subject: Integration with Enterprise Directory Services What is the standard recommendation for how identifiers get stored in enterprise directory services (e.g. LDAP)? ** *** 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 * 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
RE: Integration with Enterprise Directory Services
Would even take it to ensuring that directories use a common OID and not just making up their own attribute. Staying equivalent to Cardspace is a good thing. -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 1:00 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Integration with Enterprise Directory Services This doesn't necessarily belong into the core protocol specs, as many implementations will store OpenIDs in places other than directories. However, it would make sense to have a common convention for that ... perhaps a separate 1-page standard? On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: For CardSpace, MS and other providers store it in the SeeAlso attribute. Figured OpenID in the next rev of the spec should talk more about implementation details. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 11:57 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Integration with Enterprise Directory Services James, are you asking about the recommended format for saving an OpenID identifier in an LDAP directory? If so, I know Boeing has done some work in that area -- I can check with their directory guru. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Wednesday, January 23, 2008 1:47 PM To: specs@openid.net Subject: Integration with Enterprise Directory Services What is the standard recommendation for how identifiers get stored in enterprise directory services (e.g. LDAP)? * * *** 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 ** *** 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 * 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
Integration with Enterprise Directory Services
What is the standard recommendation for how identifiers get stored in enterprise directory services (e.g. LDAP)? * 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
RE: XACML
When an enterprise sponsors an effort, they usually are required to construct a business case for spending monies. This is easier if the enterprise knows that their goals will materialize and is harder if it is strictly an influence alone model. Since our needs aren't really about the focus of our vertical but are all about the needs of enterprises at large, I think the first step that would need to happen is for me to develop a better understanding of what other Fortune enterprises the OpenID foundation already has on board or at least has been a participant to this list in lurker mode. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Washburn Sent: Tuesday, December 11, 2007 1:27 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: XACML Hi James-- Thanks for your note. The OpenID community, made up of a considerable and growing number of developers, website operators, enterprises large and small, and of course end-users, cannot be spoken for by me alone or by the OpenID Foundation Board in any seriously comprehensive way. Of course there are members of the community who have already developed and are working assiduously now to provide added functionality supporting and serving enterprise specific requirements. Having said that, I'm fully focused these days on membership and organizational efforts for OpenID Foundation and I'm not the right person to recommend names of individuals engaged in specific efforts to support XACML, relationship modeling, and so forth. I'm certain individuals on the specs list will be able to address your substantive information request. From the Foundation's perspective, however, I would certainly appreciate the chance to talk with you about The Hartford company taking the step of becoming a pioneering member of the OpenID community from the insurance world. I hope we'll have the opportunity to talk soon. Thanks again for your inquiry. cheers, -bill Bill Washburn Executive Director OpenID Foundation +1 707 545 4823 (office) +1 650 248 6113 (cell) * 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
XACML
OpenID 2.0 seems to have closed major security gaps and is usable in a consumer context. Are their plans to figure out how to add functionality to the next version of OpenID to support more enterprise considerations including support for XACML, modeling of relationships, attestation, etc or is the focus of participants here strictly consumer oriented? * 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
OpenID support for XACML
Currently OpenID 2.0 is targeted for supporting consumer-oriented interactions. I would love to develop a sense as to when/if members of OpenID have any interest in sketching out B2B interactions where not only identity is important but also assertion of authorization information at runtime via XACML will be discussed? Players such as Vidoop can further expand their value proposition if they were to noodle XACML support as part of OpenID as there are tons of industry vertical federations that would benefit from such a solution... * 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
Thoughts on Vidoop
Recently saw a demo of Vidoop and think there approach rocks. Was curious if there is an opportunity to express an authentication strength and style as an attribute to be consumed by the relying party. * 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
Enterprise Concerns
Been silently observing many of the email exchanges over the last couple of weeks and from an end-customer perspective I am somewhat concerned. Some of the general themes I have observed are: 1. Too much focus on breaking compatibility with OpenID 1.1. While you have had some success, now is the time to break things. It is more important to get to the right long term approach earlier in the lifecycle. 2. Too much focus on being unphishable. While this is important and foward progress should happen, I don't think that this should be the only focus. I salute Kim Cameron for getting folks off their butt to solve this problem though. 3. Publish, publish, publish. Stop iterating and start publishing. The draft is way overdue and folks will not pay attention to a specification where velocity of change is occuring this frequently. 4. Tackle and discuss issues head on. I have seen several valid issues where folks way too easily dismissed the concern stating cliche phrases such as not in scope, someone else's problem, etc. 5. Not soliciting end user feedback. The observation is that there are lots of folks attempting to create a product around the spec and are simply iterating in order to be interoperable but haven't asked themselves is this what buyers of software actually desire. Many of the features that make this interesting seem to go ignored (e.g. attestation, authorization, support for XACML, etc) * 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
Java RP
I have been thinking that the best contribution I could make to OpenID would be the first enterprise that deploys OpenID into production. OpenID needs more press than it is receiving and by showing that a large Fortune enterprise is using would be a big win. I do however have one constraint in that the absolute fastest way of accomplishing deployment would be for me to identify a 100% unrestricted open source Java RP code base that I could incorporate. The notion of going through any form of procurement would not allow me to accomplish this goal. Is anyone aware of the existence of a 100% unrestricted open source Java RP code base? * 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
RE: Web Access Management
So, what will it take to move the mentioned vendors from simply being aware to actively participating? -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Sunday, April 08, 2007 2:48 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Web Access Management Tony Nadalin from IBM and Dale Olds from Novell are well aware of what is happening in OpenID. The lack of a clear IPR policy is preventing Microsoft from directly participating in the mailing lists. A number of us met at Microsoft [1] and this was one of the issues that we are working to address. btw: I think this is a better topic for [EMAIL PROTECTED] rather then specs ... [1] for the conspiracy minded, nothing happening behind closed doors, the meeting was publicly announced and anyone was welcome to attend. A number of us are kicking ourselves for not taking good notes that we could post to the list. -- Dick * 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
Web Access Management
Are there special considerations for either relying parties when they may be protected by Web Access Management products? For example, if I initially sign onto a web site using OpenID, I still will need for the Web Access Management product to create a secure cookie that contains a session identifier. Minimally, the product may have the option of taking information from any card and putting it into an unencrypted cookie. Any issues? * 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
Verisign Customer Authentication Service
VeriSign's Consumer Authentication Service authenticates customers by using real-time automation processes in combination with unique interactive question. Once consumers are properly authenticated by CAS, enterprises can be assured of their identity, and they can execute secure business transactions on the Internet. What is intriguing is that they have an identity verification service which feels like the attestation I seek. What would it take for the Verisign Identity Verification Service to attest that the chosen card is digitally signed proving who they say they are. * 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
RE: Logout
I would think that you wouldn't need to track the notion of a session but have something where the selector that tracked where the card was previously sent in terms of a list would allow you to graphically send another event. You could optionally walk a list based on each card. -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 12:29 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Logout So far, neither OpenID nor CardSpace define the notion of a session, so no common logout is possible within the standard protocols. What we do in our code at NetMesh is to add a convention where RP-URL?lid=OPENID is the same thing as submitted OpenID URL in the first form, to which the RP-URL responds with a redirect to the OP, while RP-URL?lid= means become anonymous again aka logout. There are substantial usability issues with common logout in a decentralized, internet-scale approach, however, that nobody has really solved as far as I know. * 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
RE: Logout
I think this means that the Selector MUST implement async firing capability. A user should not wait nor should this be syncronous. Likewise if a session has already been logged out, then by contract then the RP should simply ignore. -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 2:25 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Logout That might be hard from a usability perspective, and in my experience, the underlying user requirement tends to be a variation of I am about to go to lunch with the guys waiting in the hall way, log me out of all apps I'm currently logged in but take no more than 10 seconds because otherwise they will leave without me. Or at least the critical ones. (which is where it gets hard to design this right) Where sessions come in is that again from a usability perspective, the user should not have to log out from apps that he currently isn't logged into (because the session expired, for example). On Apr 6, 2007, at 10:51, McGovern, James F ((HTSC, IT)) wrote: I would think that you wouldn't need to track the notion of a session but have something where the selector that tracked where the card was previously sent in terms of a list would allow you to graphically send another event. You could optionally walk a list based on each card. -Original Message- From: Johannes Ernst [ mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 12:29 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Logout So far, neither OpenID nor CardSpace define the notion of a session, so no common logout is possible within the standard protocols. What we do in our code at NetMesh is to add a convention where RP-URL?lid=OPENID is the same thing as submitted OpenID URL in the first form, to which the RP-URL responds with a redirect to the OP, while RP-URL?lid= means become anonymous again aka logout. There are substantial usability issues with common logout in a decentralized, internet-scale approach, however, that nobody has really solved as far as I know. * 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
Logout
In thinking about this, wouldn't it be interesting if the RP could return a URL that the selector could callback on? Of course this would be optional. * 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
Attestation
The term attestation has a distinct legal meaning but within an IT context may be used interchangably with the notion of certification or periodic review. There are of course several levels of attestation. I propose that minimally OpenID incorporate the first notion where someone certifies you are who you say you are. In an enterprise environment, a manager may attest that a particular employee is still employed by them. In a user-centric world, if we could have the ability to digitally sign either a managed-card (in an enterprise setting) or across providers in a user setting along with capturing transactional attributes such as when it was signed, how long is this signature good for, the ability to revoke, etc we should be covered. Finally, an attestor should be able to choose from an enumeration of relationships such as spouse, manager/employer, service provider/customer, etc. What would it take to change the OpenID XML to incorporate? * 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
Server-to-server channel
I would think this would be better solved by leveraging the Oracle Identity Framework and using components such as AAPML and CARML Message: 3 Date: Thu, 5 Apr 2007 10:57:22 + From: Vinay Gupta [EMAIL PROTECTED] Subject: Re: Re[3]: Server-to-server channel To: Chris Drake [EMAIL PROTECTED] Cc: Martin Atkins [EMAIL PROTECTED], specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On having your private data cached: the current web model allows businesses to simply own your data into a database, correlate it across multiple databases (doubleclick) and so on. I think that to expect them to give up this privilege (and revenue stream from targeted advertising) is unrealistic, and caching OpenID data is necessary for them to do so. Therefore, I'd suggest that OpenID examines the various schemes for providing a Terms of Service **from the user end** on access to personal data: by accessing my address, you attest that you will not 1 store it for more than 30 days after our business transaction is complete, 2 share it with anybody else and so on. I seem to remember that somebody had a language for expressing those kinds of privacy preferences in a machine readable form but I'm not having any luck remembering who it was... Possibly the XRI folks know? At least at that point, users can use the penalty clause on that shrinkwrap license on their personal data to sue scumbags (and if you break these rules, you pay me $500.) HIPPA may also help. Vinay * 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
RE: Web Access Management
Based on your response, it feels kinda soft in terms of large vendor commitment. If we figure out how to get better collectively at marketing OpenID especially at end-customers and why they need it, then we can get some acceleration in terms of adoption. If you have specific names of folks at IBM then I would be game to rally many of my industry peers to put some pressure... -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 8:21 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: 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. :-) On 2-Apr-07, at 8:21 AM, McGovern, James F ((HTSC, IT)) wrote: Unlike blog sites and Internet startups, many large enteprises have purchased Web Access Management products such as Tivoli Access Manager, Netegrity Siteminder, etc where authentication doesn't occur by embedding code into the application. Is anyone directly working with any of the vendors in this space to promote OpenID? * 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: Promoting OpenID
Great to hear that you are working with salesforce.com. Would someone else on this list volunteer to work with Siebel, Peoplesoft, SAP, Intalio and Alfresco? -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 2:57 AM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Promoting OpenID On 2-Apr-07, at 8:15 AM, McGovern, James F ((HTSC, IT)) wrote: Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? We are working with salesforce.com ... * 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
Promoting OpenID
As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * 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
RE: Promoting OpenID
Gabe, I think you nailed it. The problem I run across is that my interest in using OpenID is all about getting a federation of sorts up and working within my insurance vertical which contains 250 distinct competitors. Getting emails offlist privately with vendors marketing uniquely to me is not only frustrating but doesn't actually help my goal. I don't want to choose a vendor at this time in that we all as a vertical need to agree on some other things first, so the thought of me running around attempting to coordinate a cross-company marketing event is problematic. Likewise, in terms of being in a regulated industry, I couldn't do this except in very publicly observable ways such as asking folks to blog on things, etc. Collusion is important and the best way to avoid is to ask folks who want to sell us software to market in other than a point-to-point way. -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 4:44 PM To: 'Recordon, David'; McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Promoting OpenID More likely that the people promoting OpenID to large organizations are vendors and don't particularly want to tell their competitors what they are doing. Now, imagine if there were like-minded vendors getting together to form some sort of marketing organization to promote OpenID to a variety of audiences, including large enterprises... ;-) -Gabe * 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
RE: Promoting OpenID
Imagine the waves through the technology community when end-customers stand up and preach how to code to vendors. Sadly, I am only outlining the problem space in hopes that others could step up and run with it. I think it would be appropriate for me to participate in panel discussions at upcoming industry conferences where folks from other verticals could observe the conversation but I wouldn't be permitted to have that type of interaction with vendors as NDA's, code of conduct and other situations would arise. Verisign as an organization has the best characteristics in terms of satisfying this need. Now, it is a matter of whether Verisign truly wants OpenID to be big or whether they are simply dabbling. Promotion could be as simple as putting more information about user-centric approaches on the Verisign homepage. -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 3:18 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Promoting OpenID People might be, though nothing real formal that I personally know of. You volunteering? :P --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 02, 2007 8:15 AM To: specs@openid.net Subject: Promoting OpenID As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * 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
Features for Future Versions
I originally joined this list with the hopes of injecting support for relationships, authorization and attestation into the specification but have been somewhat disappointed. I do have the following questions? 1. Will OpenID avoid incorporating features where identity selectors such as Cardspace don't support the functionality? 2. Will OpenID always constrain itself to areas where traditional PKI vendors have played (authentication) and avoid areas where PKI can't tread (authorization)? * 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
RE: HTTPS status
May I argue that a secure end-to-end encrypted channel does not always equal SSL? I know that PKI is pervasive, but wouldn't want to rule out the potential of using identity-based encryption (IBE)... Date: Wed, 28 Feb 2007 20:23:46 -0600 From: Alaric Dailey [EMAIL PROTECTED] Subject: RE: HTTPS status To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii That wording is better than I remember, but really with free certificates being readily available, and the obvious need for prtecting users data, WHY oh WHY is there even support for an unencrypted channel? Heck even Jabber is being moved to a completely secure end to end encrypted channel. With this being created brand new, why start insecure? I realize I am repeating the same thing I started a few months ago, but with MS and AOL supporting OpenID, it means a lot more users will be exposed to it, making it even more important to do it right from the beginning. Why is there such reluctance? * 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
RE: Federated Authorization
Attempting to figure out to model deeper authorizations that aren't based solely on the identity and require additional information. In your first example, it didn't take into consideration what the individual can do, only that they had different identities which needed to be correlated. -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, January 25, 2007 4:43 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Federated Authorization On 25-Jan-07, at 1:36 PM, McGovern, James F ((HTSC, IT)) wrote: Modify your scenario as follows: - Tthe College of Physicians and Surgeons says she is a surgeon and is board certified for X number of procedures - A particular hospital says she is part of their team. Likewise, they also know that she plays different roles at other hospitals. Minimally we want to know when her admission priveleges expire - The university says she is part of their faculty and teachs in both the business school and engineering school. - the government says she is the business owner of her surgical practice and also serves in a board capacity on other boards Hopefully we can develop specifications which go deeper than just matching/correlation of identity and attribute. Hi James I don't follow your last comment. Would you elaborate? -- Dick * 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
RE: Special Request: Client Certificates vs. OpenID
Even if we don't produce a white paper, we should at least produce enough insight that others such as industry analysts can provide the white paper writing services and blogging is a great way to make this happen. We should talk about the following: 1. How OpenID can benefit enterprises - enough on the consumerish stuff. Besides, success should not be based on just amount of eyeballs but where the money is. 2. What would industry vertical approaches look like using user-centric approaches - Yes we can be compatible with PKI but how about focusing on the instead of scenarios 3. A discussion on who is willing to pay - Stolen from Dick - I am of the belief that consumers won't pay and therefore putting into business context is the only way to make money. 4. If businesses are willing to pay, then what do they require and how to they beneift - anti-phishing, authorization, relationships, etc 5. How should enterprise architecture teams start thinking about identity - it needs to move away from just security folks talking about it in terms of protection mechanisms towards something that becomes a business enabler If we blog heavily on identity, relationships, authorization and attestation and the analysts need some additional stimulus to publish on it, then I will pick up expenses associated with making this happen as long as we do so quickly and in a more aggressive manner. -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Monday, January 22, 2007 3:19 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Special Request: Client Certificates vs. OpenID So I've been doing some asking around who might be interested in co-authoring some kind of white paper on the subject of user-centric identity in/for the enterprise. There are some volunteers with a variety of view points -- no guarantees that we'll manage to produce something collaboratively (cross-vendor white papers tend to be hard) -- and we'll see where that goes. That only goes partially to your point, but it is a step. On Jan 22, 2007, at 9:08, McGovern, James F ((HTSC, IT)) wrote: Last week I sent a note to the list inquiring whether anyone on this list wanted to participate in our industry vertical standards body in hopes of ratifying OpenID as an endorsed horizontal specification. In terms of preparation, it would be greatly appreciated if Dick Hardt, Johannes Ernst and other bloggers could from their blog discuss user-centric identity as a potential solution to industry vertical concerns since nothing neutral (produced by a vendor and not an insurance carrier) exists in this regard. Other industry verticals such as Pharmaceutical have embraced PKI approaches where they issue client certificates to participants. Many PKI vendors have in secret created user certificate management issues, the inability to allow for roaming users, sharing of desktops, and other concerns that I am of the belief that user-centric approaches could handle. Of course PKI-centric and user-centric don't have to be mutually exclusive but it would be wonderful if the blog entry reflected how approaches such as SAFE (pharma) would have looked in a user-centric world. * 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
Federated Authorization
I would love to see folks hear that also blog not only continue to discuss federated identity but also consider of the course of several additional postings also talk about the need for federated authorization. Consider an example where a Doctor in a hospital is having an electronic interaction with a healthcare insurance provider. The hospital should be the identity provider while the entity that licensed the Doctor for given sets of practices should be responsible for certain forms of authorization. If we only talk about identity without authorization, the conversation will result in lots of great software where folks who create them won't make any money since consumer-centric interactions have volume without corresponding revenue. * 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
Industry Verticals and Standards Bodies
The standards body for my vertical is ACORD (www.acord.org) and is where I would like to get many of my industry peers to put together standards for user-centric identity within an industry vertical context. Would be curious to know whom on this list would be interested in participating once I figure out how to get this kicked off? * 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
Requirements: Attestation
Hopefully everyone is noodling the previously sent requirements on relationship and will reply back with their own thoughts. In the meantime, I figured I would also share the requirements for attestation: * At the high level, there are two ways that attestation can work: * The identity store of the user will contain not only a pointer to whomever attests that they are whom they say they are, but also a recording of timestamp that this attestation occured along with a digitally signed indicator that it occured. Likewise the attestation should have a defined start and end date along with specifying the relationship between the two parties. * The identity store of the user will contain a pointer to the user whom they believe can vouch for them and contains an indicator of their relationship. On the attestors side, they have the option of either storing previous requests for attestation and their response and/or a pointer that defers attestation to a higher authority (redirection) * Attestation requires the ability to indicate the strength and liability of the assertion and may include the following components: * Validation of existence - Such as I know James, in context X (relationship) and assert that he is the capacity to do Z * Surety - I take responsibility for any misrepresentations, falsities or concealment of information contained within whatever I sign based on relationship * Attestation should not transition over contexts. For example, I may know Johanne in both a work and home context. He should be able to separately and distinctly separate them with distinct characteristics. * 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
AAPML
Curious if anyone here has read the AAPML specification from Oracle (http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPML-spec-08.pdf). The goal is to allow attribute authorities to specify conditions under which information under management may be used. This sounds like something that has merit for OpenID to consider... * 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
CARML
Oracle also has a similar specification named CARML (http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-CARML-spec-03.pdf) which defines how applications define their attribute requirements as it relates to identity. CARML can be used to automate configuration of identity attribute services and to expose the set of identity-related data consumed by a specific application or group of applications. * 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
Requirements: Relationships
Hopefully, everyone had the opportunity to read document I sent that outlines the business scenario(s) we are interested in using OpenID for. Figured I would start taking each theme and sharing requirements with the hope that others will react. The requirements for relationship are as follows: * OpenID should embrace and extend the learnings from the Liberty People Service which allows users to define access control for their online resources in terms of their online friends and business associates. * The notion of relationship needs a defined taxonomy to classify the type of relationship. For example, My ID and my Wife's ID would have a relationship labelled as couple where the pointer to my wife would either be wife or spouse and the inverse is also true. Likewise, wife and spouse in terms of the taxonomy need to define semantics * The notion of relationship on the above needs to have the ability to define an ACL in terms of who can see it, assert against it, etc (attribute oriented) * Yadis should be extended to support above * Taking the above defined characteristics, we can then say that relationship also needs the ability to define policies to say how relationship can be used (policy oriented). For example, My Wife and I are not only related, but according to policy she has the following priveleges against a defined set of resources. This is where XACML gets incorporated. * Relationship should also support a pointer to a set of entities along with a taxonomy that defines context. For example, James is an employee of the Hartford as well as James has a bank account with Sovereign Bank. These entities should be defined in a global namespace and be unique. * Relationships should optionally allow for the ability to specify a start and/or end date. * Relationships may potentially need a revocation / disassociation mechanism * 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
Questions on Protocol
Johannes invited me to lead the development of the specification for including relationships and authorization as part of OpenID. I have the following questions: 1. Would it be too distracting to have the conversation occur on this listserv or should the admin establish another one? 2. I would also like to get a dialog going around how OpenID would need to work in order to support notions such as Identity propagation, integration into BPM and ECM platforms and support for Identity Based Encryption * 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
