gmane.comp.web.openid.general

Re: [OpenID] Building on the OpenID PAPE specification

Peter Williams — 2008-10-07T19:41:57

Not sure about that "deal is done". Id expect a community call for comments. What the steering group can do is consider all comments and reject them, on their merits. That issue based rejection becomes part of the record, then. We thrn get passed the "anonymous designers made (uncitable) low assurance tradeoff decisions concerning protocol security, therefore a high nist authn assurance is necessarily degraded by the very nature of openid to low/no assurance" style IA-/evaluation-time claims. Its clear that wider discussion is warranted and merited, as your own post seeks to argue a case. -----Original Message----- From: Dick Hardt gmail.com> Sent: Tuesday, October 07, 2008 12:03 PM To: Brian Kelly trustbearer.com> Cc: general< at >openid.net openid.net> Subject: Re: [OpenID] Building on the OpenID PAPE specification Brian I can understand why the WG would reject something that was not within the charter. The time for you to have gotten involved would have been at the creation of the charter. Water under the bridge now. I read over your blog post, but I'm unclear on why an RP *needs* to understand the kind of authentication that was used? There is a tendency for entities to *want* as much control as possible -- but I don't follow the logic for why they *need* it. Would you elaborate?

Re: [OpenID] Building on the OpenID PAPE specification

Dick Hardt — 2008-10-07T19:03:00

Brian I can understand why the WG would reject something that was not within the charter. The time for you to have gotten involved would have been at the creation of the charter. Water under the bridge now. I read over your blog post, but I'm unclear on why an RP *needs* to understand the kind of authentication that was used? There is a tendency for entities to *want* as much control as possible -- but I don't follow the logic for why they *need* it. Would you elaborate?

Re: [OpenID] Building on the OpenID PAPE specification

Brian Kelly — 2008-10-07T14:26:47

Peter / Paul / Nat / Tatsuki: Thank you for your input on PAPE & PAPE- AM. Here is my condensed reply to the issues raised. SAML authcontext values: Peter, We haven't yet discussed these to be included in PAPE-AM. There is an auth channel security attribute that is loosely related to some of the points you raised. PAPE & PAPE-AM compatibility: Paul, it is too early in socializing the PAPE-AM specification to say if parts of it will or will not be included in PAPE. I would assume that nothing incompatible would be included in the final specification. OP falsifying information: Peter, this will always be a possibility, regardless of any changes to PAPE or the broader OpenID spec. PAPE-AM is trying to reduce the ambiguity in PAPE policies so that an OP cannot _accidentally_ falsify information about how a user was authenticated. 3rd party certified assurance program: Nat, I agree that this is a good idea to help RPs decide which OPs to trust. But, this is outside the scope of the PAPE/PAPE-AM discussion. NIST levels: Peter & Tatsuki, I agree that the NIST levels in the current PAPE spec are not sufficient in describing authentication details. Also, since they are optional, and the focus is placed on the policies (phishing-resistant, multi-factor, physical multi-factor), there is less of a chance of them being used. Brian On Oct 7, 2008, at 2:19 AM, Peter Williams wrote:

Re: [OpenID] Building on the OpenID PAPE specification

Brian Kelly — 2008-10-07T13:39:39

Dick, When we completed the first draft of PAPE-AM, we sent it to the PAPE specs working group list for input. It was promptly dismissed since it went against the PAPE WG charter, which states that only high-level policies should be included in the spec. At that point the PAPE-AM team decided that it would be a good idea to open the discussion up to the broader OpenID community to seek guidance on next-steps. I encourage the PAPE WG folks to comment on this as well. To your second point about how the RP should not care about how the user was authenticated, I agree that the trust needs to start at the OP. The main issue we were trying to address in PAPE-AM is that there is too much ambiguity in the high level policies as stated in PAPE today. This ambiguity makes it difficult for both OPs and RPs to understand what kind of authentication was actually used. Brian On Oct 6, 2008, at 7:12 PM, Dick Hardt wrote:

Re: [OpenID] Building on the OpenID PAPE specification

Peter Williams — 2008-10-07T06:19:44

I don't belong in an OpenID WG, and I belong even less in the steering group chartering WGs and issuing standards. If this was a last call on a non-WG commenting list, the steering group just got non-WG input. It is often frustrating to WG members. 5. there is no means to authenticate the communication of pape requirements from the "consumer". -----Original Message----- From: Tatsuki Sakushima [mailto:tatsuki< at >nri.com] Sent: Monday, October 06, 2008 10:24 PM To: Nat Cc: Peter Williams; Brian Kelly; general< at >openid.net Subject: Re: [OpenID] Building on the OpenID PAPE specification I proposed adding a digital signature feature into PAPE in the WG, but it was rejected because of the same reason as PAPE-AM, it is out of scope in the current charter. Welcoming more people who are interested in improving PAPE is a good thing. However rule is rule. If the scope doesn't aim that, we can do any improvement. I won't against the current spec, if most of members in the WG really want to release it as it is. But I don't think it is sufficient to handle "NIST levels" information. Since PAPE is transformed to target NIST levels(it used to be for only authentication methods as far as I know.), the purpose of the scope in the charter could be revisited and redefined. Or launching a new WG to add features which supports PAPE is another idea. My question is which is better to support implementors. If some feature is always used together, they should be in the same spec. Tatsuki Sakushima NRI Pacific - Nomura Research Institute America, Inc. Nat ????????:

Re: [OpenID] Building on the OpenID PAPE specification

Tatsuki Sakushima — 2008-10-07T05:29:47

I proposed adding a digital signature feature into PAPE in the WG, but it was rejected because of the same reason as PAPE-AM, it is out of scope in the current charter. Welcoming more people who are interested in improving PAPE is a good thing. However rule is rule. If the scope doesn't aim that, we can do any improvement. I won't against the current spec, if most of members in the WG really want to release it as it is. But I don't think it is sufficient to handle "NIST levels" information. Since PAPE is transformed to target NIST levels(it used to be for only authentication methods as far as I know.), now the premise is changed and the purpose of the WG in the charter also could be revisited and redefined. Or launching a new WG to add features which supports PAPE is another idea. My question is which is better to support implementors. If some features are always used together, they should be in the same spec. Tatsuki Sakushima NRI Pacific - Nomura Research Institute America, Inc. Nat ????????:

Re: [OpenID] Building on the OpenID PAPE specification

Tatsuki Sakushima — 2008-10-07T05:24:19

I proposed adding a digital signature feature into PAPE in the WG, but it was rejected because of the same reason as PAPE-AM, it is out of scope in the current charter. Welcoming more people who are interested in improving PAPE is a good thing. However rule is rule. If the scope doesn't aim that, we can do any improvement. I won't against the current spec, if most of members in the WG really want to release it as it is. But I don't think it is sufficient to handle "NIST levels" information. Since PAPE is transformed to target NIST levels(it used to be for only authentication methods as far as I know.), the purpose of the scope in the charter could be revisited and redefined. Or launching a new WG to add features which supports PAPE is another idea. My question is which is better to support implementors. If some feature is always used together, they should be in the same spec. Tatsuki Sakushima NRI Pacific - Nomura Research Institute America, Inc. Nat ????????:

Re: [OpenID] Building on the OpenID PAPE specification

Nat — 2008-10-07T03:23:47

In addition, a third party certified assurance program is needed. BTW, NIST levels are not particulary useful in OpenID AuthN 2.0 per se. It needs to be coupled with other extensions to support the digital signature requirement for indirect communications. =nat< at >TOKYO via iPhone On 2008/10/07, at 8:41, Peter Williams rapattoni.com> wrote:

Re: [OpenID] Building on the OpenID PAPE specification

Peter Williams — 2008-10-06T23:41:02

This is a general list vs a working group (where I don't belong). But, even so, we have heard 4 comments on pape: An op can lie and be conforming The nist levels do not satisfy the business needs of at least 1 mega op A nist level plus the inherently low assurance nature of openidauth protocol adds up to little (if anything), to those trained in information assurance doctrine Higher assurance ops need the means to signal details to the rp, so that the details would influence the rp (which presumes a conforming op is not lying). -----Original Message----- From: Paul Madsen rogers.com> Sent: Monday, October 06, 2008 3:26 PM To: Brian Kelly trustbearer.com> Cc: general< at >openid.net openid.net> Subject: Re: [OpenID] Building on the OpenID PAPE specification Hi Brian, do you have any thoughts on how PAPE-AM will, or wont, be compatible with the (as I understand the current situation) the soon to be standard PAPE My company is facing some use cases that imply reconciling or mapping SAML Authentication Context and PAPE, so Im concerned about a split here thanks paul Brian Kelly wrote: -- Paul Madsen e:paulmadsen < at > ntt-at.com NTT p:613-482-0432 m:613-302-1428 aim:PaulMdsn5 web:connectid.blogspot.com _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general

Re: [OpenID] Building on the OpenID PAPE specification

Dick Hardt — 2008-10-06T23:12:04

Brian: did you participate in the PAPE spec? That would have been the place to have brought up this issue. Although I did not participate in the PAPE specification (only so much time) -- I was supportive of the high level policies vs specific technologies. The RP really does not (well, *should* not) care about how the user was authenticated, just about how much certainty the OP has that it is the user. It is the OP making the assertion after all. Keep in mind I can have an OP that says that all the factors were used, even if they were not.

Re: [OpenID] Building on the OpenID PAPE specification

Paul Madsen — 2008-10-06T22:25:57

Hi Brian, do you have any thoughts on how PAPE-AM will, or wont, be compatible with the (as I understand the current situation) the soon to be standard PAPE My company is facing some use cases that imply reconciling or mapping SAML Authentication Context and PAPE, so Im concerned about a split here thanks paul Brian Kelly wrote:

Re: [OpenID] Building on the OpenID PAPE specification

Peter Williams — 2008-10-06T22:23:03

Any chance of the values of the values registered in the OASIS SAML authcontext world being applied to this? Or, does there have to be yet another registration process (for no particular reason): EAP, SAML, OpenID? If I bind to an OP using EAP-TLS as an act of user auth, surely evidence from that TLS session between supplicant and authenticator could accompany the PAPE-AM signal issues by theOP. E.g. If the EAP-TLS session uses SAML HOK for TLS client auth (rather than X.509 client certs and signatures), the confirmation component of the SAML assertion could accompany the PAPE-AM signals. How about that for a bit of websso convergence? The quality of the OpenID handshake/session/trustfabric would not necessarily degrade the user authentication act, then. Its just a conduit. -----Original Message----- From: general-bounces< at >openid.net [mailto:general-bounces< at >openid.net] On Behalf Of David Recordon Sent: Monday, October 06, 2008 2:36 PM To: Brian Kelly Cc: general< at >openid.net Subject: Re: [OpenID] Building on the OpenID PAPE specification Hey Brian, I'm jumping on a plane so only got a chance to skim this but it seems like a great post on some additional needs to use OpenID in higher trust environments. Thanks for taking the time to write up your thoughts and share them with the community. --David --- Sent from my iPhone classic. On Oct 6, 2008, at 5:29 PM, "Brian Kelly" trustbearer.com> wrote: _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general

Re: [OpenID] Building on the OpenID PAPE specification

David Recordon — 2008-10-06T21:35:45

Hey Brian, I'm jumping on a plane so only got a chance to skim this but it seems like a great post on some additional needs to use OpenID in higher trust environments. Thanks for taking the time to write up your thoughts and share them with the community. --David --- Sent from my iPhone classic. On Oct 6, 2008, at 5:29 PM, "Brian Kelly" trustbearer.com> wrote:

[OpenID] Building on the OpenID PAPE specification

Brian Kelly — 2008-10-06T21:28:56

A few months ago, some members from the OATH community and I got together to take a fresh look at the PAPE spec, what it was trying to accomplish, and how well it could be implemented. We started holding semi-weekly conference calls and over the period of a couple months we drafted up a slightly new take on PAPE. The main difference is that we defined a specific set of authentication methods, rather than only using high-level policies. After long discussions we found that there was too much ambiguity in the high-level policies as defined today in PAPE. We created a draft of our modified specification, termed PAPE-Authentication Mechanisms (PAPE-AM), and we are beginning to socialize the concepts in that draft. I published a blog post summarizing our motivations, and wanted to share it with the greater OpenID mailing list. http://openidtrustbearer.wordpress.com/2008/10/06/building-on-the-openid-pape-specification/ I would appreciate hearing the thoughts of the readers on this mailing list. Please respond publicly, or feel free to contact me directly. Thank you, Brian -- Brian Kelly TrustBearer Labs http://trustbearer.com

Re: [OpenID] Moving OpenID code repositories

James Tindall — 2008-10-06T09:24:27

I maintain an Openid library for the opensource php framework kohana - it's currenlty up on google code in a repository with other kohana modules. http://code.google.com/p/kohanamodules/wiki/Openid I'd be happy to move it to a common openid google code repository or to github. james Andrew Arnott wrote:

Re: [OpenID] Moving OpenID code repositories

Andrew Arnott — 2008-10-06T03:44:00

_______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general

Re: [OpenID] Moving OpenID code repositories

Chris Messina — 2008-10-06T03:40:26

Touché. Good point. I'd recommend that you go star this issue in order to express your desire for Google Code to support OpenID: http://code.google.com/p/support/issues/detail?id=813 And make sure to start #414 to get OAuth support as well: http://code.google.com/p/support/issues/detail?id=414 As it is, I'm not sure that anyone has actually patched SVN or git to work with OpenIDs, so whether the repository allow for OpenID authentication is somewhat moot when it comes to managing source code. I also just attempted to hook up my OpenID with Sourceforge account and it wasn't exactly ... user friendly. But that's besides the point. My interest is in making it as simple and straightforward as possible for folks to get the resources that they need to adopt OpenID -- and so far both Google Code and Github, with their simple, basic designs and features support that goal -- so I'm with you that it'd be ideal if either of them supported OpenID, but it's not necessary for this change to support my original goal. Chris On Sun, Oct 5, 2008 at 8:26 PM, Peter Williams rapattoni.com> wrote:

Re: [OpenID] Moving OpenID code repositories

Peter Williams — 2008-10-06T03:26:44

Can one login to google code using an openid? If not, would it not make more sense to endorse a code repository that does? Perhaps im being disingenuous about money and endorsement politics within the vc community, here. More likely, im just showing my ignorance about google code. Have openid. Willing to do trial of applying it to access google code project. Any takers? -----Original Message----- From: David Recordon sixapart.com> Sent: Sunday, October 05, 2008 8:16 PM To: Chris Messina gmail.com> Cc: Josh Hoyt gmail.com>; Scott Kveton kveton.com>; Michael Richardson gobyairship.com>; OpenID List openid.net>; dlehn< at >gmail.com gmail.com> Subject: Re: [OpenID] Moving OpenID code repositories +1 for Google Code (if this happens), but have you been talking with the current library maintainers to see if they would even move their code? --David On Oct 5, 2008, at 10:26 PM, Chris Messina wrote: _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general

Re: [OpenID] Moving OpenID code repositories

Chris Messina — 2008-10-06T03:23:52

I talked to Brian Ellin personally at the PoCo summit. Otherwise, no, I have not. I'm primarily interested in the OpenID Enabled libraries for now -- and then we can look at how we could go about improve the specific libraries per language and inviting each maintainer in once the move has been made. It's kind of a chicken and egg problem, with the most momentum to be gained from having the Janrain libraries moved first and then corralling the others, where there's interest. I know that a bunch of the OAuth libraries are maintained outside of the main Google Code repository, but we try to keep the majority of them available and accessible in one place, unless it makes sense to maintain them elsewhere (as in the case of Ruby and Perl). If other maintainers are following this thread, I'd be eager to hear your thoughts on this proposal. Chris On Sun, Oct 5, 2008 at 8:15 PM, David Recordon sixapart.com> wrote:

Re: [OpenID] Moving OpenID code repositories

David Recordon — 2008-10-06T03:15:54

+1 for Google Code (if this happens), but have you been talking with the current library maintainers to see if they would even move their code? --David On Oct 5, 2008, at 10:26 PM, Chris Messina wrote:

[OpenID] Moving OpenID code repositories

Chris Messina — 2008-10-06T02:26:20

I've been having conversations with folks about the current OpenID libraries lately and it seems to me that it would be highly valuable to both consolidate the existing [good] libraries, to get more visibility and transparency into their development, to increase the number of contributors, to give the foundation more direct management of the codebase, to open up the support queue, to enable branching, and to also go about creating separate libraries for each respective language, rather than just using ports of the Python libraries. Yes, this is a tall order, but given the experience I've had with pushing the development of OAuth libraries (http://oauth.net/code), I think we need to shift where and how the development happens to get more momentum going and make it easier to manage project access. I propose that we make use of either Google Code or Github. I'm not looking for a religious battle here; I'm personally more familiar and comfortable with Google Code, but Github has proven to be a rather excellent tool for distributed/decentralized development. This request is primarily initiated from conversations I've had in the course of working on the DiSo Project -- both from WordPress and Drupal devs... and from folks who have submitted patches to the openidenabled dev list [1] which have been ignored. Such impressions can lead to lasting impressions, and if anything, we need to radically improve the community and developer footprint of OpenID -- and turn it into a leading open source initiative. Working with top tier tools is the place to start. Now, there's one caveat here that requires a nod from the Sourceforge project maintainers: the Sourceforge project (http://openid.sourceforge.net/) currently redirects to the wiki. This means that the "OpenID" project name is reserved on Google Code, so if we want to make use of that project, the folks who own the Sourceforge project would need to give us the go-ahead to reuse that project name (Google reserved all the Sourceforge project names to prevent squatting). If yes, we can go about getting the projects started up -- perhaps following the architecture of the OAuth repository: http://code.google.com/p/oauth/source/browse/#svn/code I look forward to your thoughts and feedback. Thanks! Chris [1] http://lists.openidenabled.com/mailman/listinfo/dev