IGF: CARML

2009-04-13 Thread McGovern, James F (HTSC, IT)
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

2009-02-09 Thread McGovern, James F (HTSC, IT)


-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

2009-02-06 Thread McGovern, James F (HTSC, IT)
 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

2009-02-05 Thread McGovern, James F (HTSC, IT)
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

2009-02-04 Thread McGovern, James F (HTSC, IT)
 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

2008-12-05 Thread McGovern, James F (HTSC, IT)
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

2008-12-04 Thread McGovern, James F (HTSC, IT)
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

2008-08-15 Thread McGovern, James F (HTSC, IT)
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

2008-04-07 Thread McGovern, James F (HTSC, IT)
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

2008-04-02 Thread McGovern, James F (HTSC, IT)
 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


Web Services

2008-03-19 Thread McGovern, James F (HTSC, IT)
 Out on the Wiki is a discussion on creating a WS-Security profile to
support OpenID. Is anyone planning on taking this further?


*
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

2008-03-10 Thread McGovern, James F (HTSC, IT)
 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

2008-02-27 Thread McGovern, James F (HTSC, IT)
 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

2008-02-26 Thread McGovern, James F (HTSC, IT)
 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

2008-02-26 Thread McGovern, James F (HTSC, IT)
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

2008-02-18 Thread McGovern, James F (HTSC, IT)
 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

2008-02-15 Thread McGovern, James F (HTSC, IT)
 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

2008-02-04 Thread McGovern, James F (HTSC, IT)

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

2008-02-04 Thread McGovern, James F (HTSC, IT)
 
 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

2008-02-01 Thread McGovern, James F (HTSC, IT)
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

2008-01-25 Thread McGovern, James F (HTSC, IT)
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

2008-01-25 Thread McGovern, James F (HTSC, IT)
 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

2008-01-24 Thread McGovern, James F (HTSC, IT)
 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

2008-01-24 Thread McGovern, James F (HTSC, IT)
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

2008-01-23 Thread McGovern, James F (HTSC, IT)
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

2007-12-12 Thread McGovern, James F (HTSC, IT)
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

2007-12-11 Thread McGovern, James F (HTSC, IT)
 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

2007-10-31 Thread McGovern, James F (HTSC, IT)
 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

2007-10-23 Thread McGovern, James F (HTSC, IT)
 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

2007-05-29 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-11 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-09 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-06 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-06 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-06 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-06 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-06 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-05 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-05 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-04 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-04 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-03 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-03 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-03 Thread McGovern, James F \(HTSC, IT\)
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

2007-04-02 Thread McGovern, James F \(HTSC, IT\)
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

2007-03-01 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-25 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-23 Thread McGovern, James F \(HTSC, IT\)
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


RE: Special Request: Client Certificates vs. OpenID

2007-01-22 Thread McGovern, James F \(HTSC, IT\)
My question was a little different than your response. I understand that Client 
Certificates can be used in addition to, but I was asking about documenting 
scenarios in blog entries where it could be used instead of. For example, if 
the Pharma SAFE 
(http://www.cybertrust.com/pr_events/press_releases/2005/03/29/) where to look 
at their problem space in 2007, would they have chosen client certificates.

-Original Message-
From: Alaric Dailey [mailto:[EMAIL PROTECTED]
Sent: Monday, January 22, 2007 2:02 PM
To: McGovern, James F (HTSC, IT); specs@openid.net
Subject: RE: Special Request: Client Certificates vs. OpenID


Client certificates could easily be used to extend openID, and since (last
time I checked) the authentication process was entirely up to the IdP, a
client certificate based IdP should be open to be created. 

Most CAs have created a problem because they only allow a user to use their
certs (mostly because CAs don't all follow the same persona verification
standards, and to a lesser degree politics). Now, over at StartCom, Eddy has
created a system where users are allowed to register any certificate they
like to login, very much like the USPS has done for the Electronic Post
Mark.



*
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


Federated Authorization

2007-01-18 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-18 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-18 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-09 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-09 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-05 Thread McGovern, James F \(HTSC, IT\)
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

2007-01-02 Thread McGovern, James F \(HTSC, IT\)
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