gmane.comp.web.openid.general

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 d

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

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 o

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

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 goa

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: ____________________________________________

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

[OpenID] sourceforge RP

Peter Williams — 2008-10-05T04:57:50

Just used the sourceforge RP for the first time. More Congratulations OpenID Foundation! The SF integration is a mix of google, plaxo and wrongess. First of all, its integration with sreg/ax seems excellent. Plaxo like, enrollment gave way to account linking in a seemless and natural manner. (I didn't check if one can bind multiple openids.) Perhaps "wrongness" in SF "arming" its now-enrolled openid login only after the user has confirmed receipt of a URL (in an email)is the wrong turn of phrase. The open nature of UCI perhaps requires that an additional confirmation round is used by the RP. In this way, the openid is essentially a assurance surrogate of the email address. Though nothing to do with openid, one sees a opportunity for a linkup with an RP-specific reputation metric: https://sourceforge.net/services/reputation.php Myopenid and the phonefactor integration continues to work almost perfectly, and entirely naturally. For unknown reasons, the very first phonefactor auth attempt failed, perhap

[OpenID] Using EAP-TLS as a bearer for OpenID

Peter Williams — 2008-10-05T04:05:32

http://www.ietf.org/rfc/rfc2716.txt anyone interesting in cooperating on an EAP-TLS/PPP bearer experiment, communicating OpenID2 Auth? The intent of the project would be to exploit careful design and use of the TLS dandshake components, when handling multiple sessions and session resumes. Not for the faint of heart; should already understand the design of the SSL handshake, the SSL record layer, the crypto session hijacking countermeasures, the difference between SSLv2 and SSLv3 regarding trusted session offloading/caching, etc. Familiarity with PPP fragmentation and SSL fragmentation/pipeline handling and model for hardware acceleration would be an asset.

[OpenID] Your participation in the "OpenID'09 Vision"

Snorri — 2008-10-04T08:59:53

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

[OpenID] TR: ICANN - dotOpenID Has Found Its First Sponsor

Snorri — 2008-09-30T13:44:26

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