Re: [OpenID] Signing method for XRD
-- and many complaints about how it's not possible to get it to work reliably given the software stacks currently in use. The difficulties with canonicalization-for-signing in OAuth implementations have also reinforced my belief that it's much better to err on the side of the robust and simple. Signing a stream of uninterpreted bytes cuts out a whole slew of failure modes, and the ones that remain are debuggable -- the bytes match or they don't, and standard tools can tell you which. It means it's possible to verify a signature with curl + a command line utility. These are all very good things. (As a side note, it would also make the content type orthogonal to the signature code -- this is a good thing.) So, +1 for the simplest form of signing that could possibly work. -John Johannes Ernst wrote: I proposed something I called XML-RSig for similar reasons a few years ago: http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html RSig for Really simple Signature. The trouble for OpenID and XRD and so forth is that it is not our core competency -- and shouldn't be -- to innovate around things that really aren't our business. Signing XML documents isn't our business. On the other hand, the people whose business it should be somehow seem to be asleep at the wheel, as the problems are well-known and somehow aren't being addressed, and haven't for years. It seems to me that the best way out of this conundrum is: 1. to foresee, architecturally, the use of several different ways of constructing signatures, as the matter clearly isn't settled 2. to make sure that high-end approaches (like XML-DSIG) work well, but low-end approaches (like XML-RSIG) work just as well 3. to maintain a best practices document that says today, choice X is your best bet, and we say that because based on our market research, X has the highest market share in terms of implementors today. As we all know, any problem in computer science can be solved by adding a level of indirection. This may well be one of those cases. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs -- David Garcia CTO Tractis - Online contracts you can enforce http://www.tractis.com -- Tel: (34) 93 551 96 60 (ext. 260) Email: david.gar...@tractis.com mailto:david.gar...@tractis.com Blog: http://blog.negonation.com Twitter: http://twitter.com/tractis -- David Garcia CTO Tractis - Online contracts you can enforce http://www.tractis.com -- Tel: (34) 93 551 96 60 (ext. 260) Email: david.gar...@tractis.com mailto:david.gar...@tractis.com Blog: http://blog.negonation.com Twitter: http://twitter.com/tractis ___ 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
Re: [OpenID] Signing method for XRD
When we first started discussing the topic, we started off with something quite similar (in fact a little more simpler) than RSig. The flow of our discussion over the last 6 months were like this: The trait was like this. 1. XRDS has been using SAML constrained version of XML DSig, but nobody implemented it. There has to be something wrong in specifying this signature method. (Also, we know that SAML XML DSig created a lot of compatibility issues in the field. ) 2. We have studied the current XML DSig implementations for script languages, and found that in most case, we have to link the C libraries. This is no go for many hosting environment, so we decided to make a simple alternative Simple Sign. 3. We came up with Simple Canonicalization + X.509(RSA-SHA) Signature method, which can be implemented widely in many scripting languages. 4. Even this Simple Canonicalization raised an issue of comaptibility, so decided to do no Canonicalization at all. 5. This seemed to require a detached signature, but it would not be able to deal with sequence of XRDs. (Detached Sig) 6. Thus, we created SignedXRD (SXRD) method so that it can be inline, which is currently in http://wiki.oasis-open.org/xri/XrdOne/SimpleSign XRD sig=signature sigalg=http://www.w3.org/2000/09/xmldsig#rsa-sha1; certuri=pem file location data=BASE64 of the payload / 7. When writing a spec for Detached Sig, it has been found that we are rewriting a lot of what has been in XML Dsig. Thus, XML Dsig with no canonicalization was explored. 8. Then, it was argued that SAML core ch.5 version of XML DSig is simple enough and there are scripting language implementations as well, though they need the C Libraries to be linked. 9. We are back to the square ONE. (= We are here.) My main concern about XML DSig are as follows: 1. Perception: If developers think it is too much, it is not going to be deployed. 2. Performance: In Java 6, it is not an issue, but in the past, it seems it has been. 3. Support: There are linkable C libraries for script languages, but are they deployed or deployable? For example, I do not think that can be deployed on Google AppEngine Python. (Or is it? Please let me know!) 4. If support is not there, is it easy to write your own? 5. What about the performance then? etc. My Concern about Simple Sign only is 1. It is new: do people implement it? My Concern about supporting both are: 1. Is it going to be too much to ask library writers to support both XML Dsig and Simple Sign? As a ever indecisive person, I tend to opt for Both option, but what do you guys think of it? =nat On Thu, Jun 11, 2009 at 2:01 PM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: I proposed something I called XML-RSig for similar reasons a few years ago: http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html RSig for Really simple Signature. The trouble for OpenID and XRD and so forth is that it is not our core competency -- and shouldn't be -- to innovate around things that really aren't our business. Signing XML documents isn't our business. On the other hand, the people whose business it should be somehow seem to be asleep at the wheel, as the problems are well-known and somehow aren't being addressed, and haven't for years. It seems to me that the best way out of this conundrum is: 1. to foresee, architecturally, the use of several different ways of constructing signatures, as the matter clearly isn't settled 2. to make sure that high-end approaches (like XML-DSIG) work well, but low-end approaches (like XML-RSIG) work just as well 3. to maintain a best practices document that says today, choice X is your best bet, and we say that because based on our market research, X has the highest market share in terms of implementors today. As we all know, any problem in computer science can be solved by adding a level of indirection. This may well be one of those cases. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Signing method for XRD
Hi Allen, Thanks for your input. What do you think of the proposal on http://wiki.oasis-open.org/xri/XrdOne/SimpleSign ? Would it be simple enough? (Well, I do not think it can go any simpler than that but... ;-). Would you implement it? On Thu, Jun 11, 2009 at 1:52 PM, Allen Tom a...@yahoo-inc.com wrote: Hi Nat, Generating signatures is tricky, and XMLDSig is trickier than most. That being said, there are libraries that do it, and they do seem to work. First of all, I'd be happier to see something other than XML, but if XML has already been decided on, then I would not mind seeing something other than XMLDSig, if the alternative is significantly for developers to generate than XMLDSig. Allen Nat Sakimura wrote: Hmmm. Perhaps I did not spell my intent in the original mail well enough. My question was: (1) Is XML DSig easy enough for you developers to use? (2) Is XML DSig supported in your environemnt? e.g., Google AppEngine, Force.com, your hosting environment, your own server, etc. (3) If either (1) or (2) is negative, are you aimiable to use a very simple alternative to it, or you do not bother signing XRD at all? Best, =nat On Thu, Jun 11, 2009 at 4:16 AM, Santosh Rajan santra...@gmail.comwrote: I agree that in XML they are not equivalent. Yes but the signing process itself is binary, it has nothing to do with text or its meaning. Hans Granqvist wrote: Once you digitally sign a document, though physically the document remains in tact and retains its content type, after the act of signing, it is really a frozen bunch of bits. And if you dont make that distinction you get into all sorts of tangles. And that was the mistake made by XMLDSig. In other words after signing the Content-Type should be binary, whatever you want to call it. After verification it takes up its original Content-Type. In XML these two are equivalent: A signing process needs to understand this, and that is what XML Dsig does. XML was not defined to be a wire format. Hans ___ general mailing list gene...@openid.net http://openid.net/mailman/listinfo/general - Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/Signing-method-for-XRD-tp23956678p23969137.html Sent from the OpenID - General mailing list archive at Nabble.com. ___ general mailing list gene...@openid.net http://openid.net/mailman/listinfo/general -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- ___ general mailing listgene...@openid.nethttp://openid.net/mailman/listinfo/general -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OAuth Hybrid and UI ML?
Hi. I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not listed on http://openid.net/mailman/listinfo/ . http://openid.net/mailman/listinfo/ To make sure equal participation, we should make it possible for people to find out about them. Are they established at all? Where is the discussion being conducted right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Requiring Pseudonymous Identifier
Sorry for a slow response. This week is especially busy for me... I borrowed the notion from Austrian Citizen ID system. In there, the services are divided into sectors. A sector may span several agencies. They call ID as PIN (Personal Identification Number). There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard. Then, sector sepcific PIN (ssPIN) is calculated in the manner of : SHA1(sPIN + SectorID) (Note, there is a bit more details but...) I have thrown OP secret into it. To avoid the analytic attack, I agree that it is better to use individual secret, as some of you points out. Regards, =nat On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com wrote: On 12-May-09, at 1:36 AM, Nat Sakimura wrote: Reason for using RP's Subject in XRD instead of simply using realm is to allow for something like group identifier. would you elaborate on the group identifier concept? This is just one idea. Downside of this approach is that we need to set up a WG. I am sure there are more ideas. It might be possible to utilize AX so that it will only be a profile that does not require a WG. So shall we start discussing which direction we want to go forward? sure! -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Requiring Pseudonymous Identifier
On Thu, May 14, 2009 at 12:46 AM, SitG Admin sysad...@shadowsinthegarden.com wrote: Having two simultaneous threads on two closely related lists, with the same subject line, can be confusing. Right. The original that I raised is what I have explained copule of hours ago. It is the identifier of the RP Service (which may span multiple domains). This has impact onto the psudonymous identifier generation. As I have explained in my previous post, there are some real requirements for it, esp. in the government sector. In contrast, identifier for group of individual while interesting is not directly related to the psudonym issue. So, shall we separate this topic into another thread with more appropriate subject? =nat ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Requiring Pseudonymous Identifier
I think RP discovery is needed anyways. For deciding whether RP wants psudonym for this transaction or not, I am not sure if RP discovery alone is enough, though. RP might want non-psudonym for a particular type of transaction. So, yes, RP's XRD would be able to specify the default behaviour, but it would also be useful to be able to override it per transaction. As a matter of fact, I do not strongly feel that we should bake the psudonym generation algorithm into the spec. However, thinking concretely would clarify the requirement to other portions, like what has to be written in the XRD, etc. so I think it is useful. To indicate the quality of the identifier and the assertion, we should utilize PAPE. =nat On Thu, May 14, 2009 at 1:28 AM, George Fletcher gffle...@aol.com wrote: I'm perfectly fine with using RP discovery as a mechanism for the RP to specify what policy it requires. I believe that unsolicited assertions are going to become more common, so we need to support it. What I don't want OpenID to do is specify the actual syntax of the pseudonymous identifier. I agree that the RP has to trust the OP (in some sense) or make it's own determination that the OP is not honoring the RP's wishes and then take some action. For RP's behind firewalls, it would be nice to allow them some mechanism other than RP discovery to assert their requirements, but that should preclude the discover option. Thanks, George Andrew Arnott wrote: leaves out the scenario of unsolicited assertions.A new directed identity value that the RP passes to the OP to indicate it wants a psuedononymous identifier. Consider this: An OP needs to perform RP discovery (already), and probably does so before sending an unsolicited assertion in order to find out what the assertion receiving URI would be for a given realm. DNOA does this already. If that RP's XRDS document included a TypeURI element that had a special psuedononymous-identifier-only-please value the OP could pick up on this, and send the unsolicited assertion using the appropriate type of claimed_id. Likewise, when an RP sends an ordinary directed identity request to an OP, the OP would again notice the RP's XRDS during RP discovery and see what kind of identifier the RP wants and assert accordingly. Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP discovery at all. Perhaps to help the RP detect whether the OP respected its wishes would be to send a PAPE extension or some other openid.* parameter to say yes, this is a pseudo- identifier. RPs have no way to analytically be certain that some identifier is psuedononymous anyway, so ultimately the RP has to trust the OP (whether implicitly or through a white list is up to the RP). -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 8:44 AM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: I don't think OpenID should specify how pseudonymous identifiers are generated. That should be up to the OP. But I like the idea of using a fixed URI as the claimed_id value to specify the behavior desired by the RP. If, however, we need to grow this to cover anonymous based identifiers (i.e. the claims based models from earlier in this thread) then it might make sense to look at a PAPE extension that covers the type of identifier requested. Thanks, George Nat Sakimura wrote: Sorry for a slow response. This week is especially busy for me... I borrowed the notion from Austrian Citizen ID system. In there, the services are divided into sectors. A sector may span several agencies. They call ID as PIN (Personal Identification Number). There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard. Then, sector sepcific PIN (ssPIN) is calculated in the manner of : SHA1(sPIN + SectorID) (Note, there is a bit more details but...) I have thrown OP secret into it. To avoid the analytic attack, I agree that it is better to use individual secret, as some of you points out. Regards, =nat On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote: On 12-May-09, at 1:36 AM, Nat Sakimura wrote: Reason for using RP's Subject in XRD instead of simply using realm is to allow for something like group identifier. would you elaborate on the group identifier concept? This is just one idea. Downside of this approach is that we need to set up a WG. I am sure there are more ideas. It might be possible to utilize AX so that it will only be a profile that does not require
Re: Identifier for group of individulas
My interpretation is that the fragment does not necessarily mean a new user, but it just differentiate among different users. =nat On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott andrewarn...@gmail.com wrote: Fragments are valid URI parts. But they are unique in that a web browser never sends them to the server. The OpenID 2.0 spec specifically calls out fragments as valid ways that OPs can indicate to RPs that a new user controls this identifier. So in fact that may be a problem. Multiple users could be asserting control of the identifier (minus the fragment). The OpenID 2.0 spec at least hints that OPs will use this generational #fragment to indicate a new user controls the identifier (identifier recycling). An RP that sees a new fragment attached to a claimed_id may assume (perhaps rightly) that the old user is now gone and delete settings for the old user. If the OP habitually sticks on random goo to the end of an identifier via its #fragment, then that interpretation by the RP would not be safe. I don't know if others read the spec that way though. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan santra...@gmail.com wrote: I am not sure about fragments. I dont think the fragment falls under the deifinition of URI. see rfc 3986. The group can be indentified within the path part, assuming all members of the group belong to the same OP and the group is known while issuing the OpenID. In that case we dont need anything to define at the OpenID level. Or am i missing something here? Andrew Arnott wrote: Appending a fragment at least will help the RP distinguish between identifiers. And in the short term it has the merit of not requiring any spec changes. But I still would like to see a group membership claim kept separate from the identity claim, perhaps via the claim discovery I described in the other thread. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura sakim...@gmail.com wrote: My previous post on pseudonymous identifier seemed to have kicked off interesting but orthogonal discussion of identifier for group of individuals (like school class, friends, etc.) Please use this thread instead for this discussion. Just to put an context to the discussion, I can put one deployed example of this type of identifier use. mixi, the largest Japanese SNS, is using the concept of group identifier. For example, to prove you are a friend of mine, you can authenticate with the identifier https://id.mixi.jp/nat/friend The verified identifier would be something like https://id.mixi.jp/nat/friend#hashOfYourId etc., if I rememer right. As you can see, it requires no change in the OpenID AuthN 2.0 nor an extension. Anyways.. my 2c. =nat -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs - Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/Identifier-for-group-of-individulas-tp23525446p23526064.html Sent from the OpenID - Specs mailing list archive at Nabble.com. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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
Re: Identifier for group of individulas
Well, I think this just says that the full URI MUST not be reassigned to different (group of) entities, that the verified identifier will be always this non-recycled full identifier. =nat On Thu, May 14, 2009 at 2:39 AM, Andrew Arnott andrewarn...@gmail.com wrote: From the spec: 11.5.1. Identifier Recycling OpenID Providers with large user bases can use fragments to recycle URL Identifiers if it is so desired. When reassigning a URL Identifier to a new end user OPs should generate a new, unique fragment part. The full URL with the fragment part constitutes the Claimed Identifier in positive assertions, therefore Relying Parties will distinguish between the current and previous owners of the fragment-less URL. This mechanism allows the (presumably short, memorable) recycled URL Identifiers without the fragment to be used by end users at login time and by Relying Parties for display purposes. This smells hugely of the idea that only one user controls an identifier at a time. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 10:27 AM, Nat Sakimura sakim...@gmail.com wrote: My interpretation is that the fragment does not necessarily mean a new user, but it just differentiate among different users. =nat On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott andrewarn...@gmail.com wrote: Fragments are valid URI parts. But they are unique in that a web browser never sends them to the server. The OpenID 2.0 spec specifically calls out fragments as valid ways that OPs can indicate to RPs that a new user controls this identifier. So in fact that may be a problem. Multiple users could be asserting control of the identifier (minus the fragment). The OpenID 2.0 spec at least hints that OPs will use this generational #fragment to indicate a new user controls the identifier (identifier recycling). An RP that sees a new fragment attached to a claimed_id may assume (perhaps rightly) that the old user is now gone and delete settings for the old user. If the OP habitually sticks on random goo to the end of an identifier via its #fragment, then that interpretation by the RP would not be safe. I don't know if others read the spec that way though. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan santra...@gmail.com wrote: I am not sure about fragments. I dont think the fragment falls under the deifinition of URI. see rfc 3986. The group can be indentified within the path part, assuming all members of the group belong to the same OP and the group is known while issuing the OpenID. In that case we dont need anything to define at the OpenID level. Or am i missing something here? Andrew Arnott wrote: Appending a fragment at least will help the RP distinguish between identifiers. And in the short term it has the merit of not requiring any spec changes. But I still would like to see a group membership claim kept separate from the identity claim, perhaps via the claim discovery I described in the other thread. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura sakim...@gmail.com wrote: My previous post on pseudonymous identifier seemed to have kicked off interesting but orthogonal discussion of identifier for group of individuals (like school class, friends, etc.) Please use this thread instead for this discussion. Just to put an context to the discussion, I can put one deployed example of this type of identifier use. mixi, the largest Japanese SNS, is using the concept of group identifier. For example, to prove you are a friend of mine, you can authenticate with the identifier https://id.mixi.jp/nat/friend The verified identifier would be something like https://id.mixi.jp/nat/friend#hashOfYourId etc., if I rememer right. As you can see, it requires no change in the OpenID AuthN 2.0 nor an extension. Anyways.. my 2c. =nat -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs - Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/Identifier-for-group-of-individulas-tp23525446p23526064.html Sent from the OpenID - Specs mailing list archive
Re: OpenID Security
Actually, we have previously tested Fortify. As you have stated, it is not possible to use it without a professional service. It is merely a tool to assist the security analyst. =nat On Fri, Feb 6, 2009 at 5:48 AM, Darren Bounds dbou...@gmail.com wrote: 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 On Thu, Feb 5, 2009 at 3:08 PM, McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com wrote: 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 -- Thank you, Darren Bounds ___ 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
Re: OpenID Mobile Profile?
:-) So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil translated also posted a message to this list, but it apparently has gone into a moderation queue for some reason... So, here is his text: Hi. I'm Toru Yamaguchi (=zigorou). I'm interested in OpenID for Mobile. My presentation of OpenID for Mobile(Jp) was translated by wil(=wil). http://dready.org/blog/2009/01/02/mobile-openid-in-japan/ -- Now, as to the mobile/artifact mode, I kind of feel that it probably is better to establish a second channel. So, the flow is like: 1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.) 2. RP posts this to the OP's artifact mode endpoint published in OP's XRD. 3. OP issues a nonce as an artifact or ticket. 4. RP redirects the browser with this artifact. 5. OP, receiving this artifact, reconstructs the OpenID message from the post received in step 2 above. 6. Credentail presentation etc. happens as usual, and OP verifies the user's identity. 7. OP creates a positive response and stores it with the artifact as the key. 8. OP redirects the browser with the artifact to the RP. 9. RP fetches the response created in 7. and examines it to authorize the access. Nice thing about this is that it probalby is going to be a very little code addition to the current libraries. The difference between this flow and the SAML artifact binding is that in case of SAML, the artifact/ticket is created by the RP and OP goes and fetch the request from RP. I chose this design because RP can be inside the firewall when OP is on the internet which is a more likely use case for OpenID. =nat On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: In which case, back to your original question: Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? My answer would be Yes. On Jan 29, 2009, at 22:14, Nat Sakimura wrote: There are two issues involved. 1) URL length etc. limitations 2) User interface 1) has impact on 2). For instance, we want to avoid the users pressing buttons when redirecting. And, in many cases, we do not have javascript. This means we are left with GET and this URL length limitation becomes an issue. 2) cannot be solved globally because it could very well be somewhat dependent on the carrier implementation and handset capability. For most of the phones in Japan, we can get unique id for each handset at http level fairly securely so we can depend on it to avoid any typing (not even username etc.). This was one of the factor why m-commerce got so popular in Japan. In many other markets, e.g., the U.S., this is not granted. Thus, some other means are required. I know, WIl Tan of Maleysia is working something on iPhone in this regard. Essentially, it needs to be solved per carrier or per handset class (e.g., mid-p enabled phones, etc.), I think. =nat On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: Are you talking about URL length limitations for the identifiers that users need to enter, or for URLs that are being sent around as part of the protocol? IMHO the most important question to ask for mobile devices is: can we do without typing anything? On Jan 29, 2009, at 16:56, Nat Sakimura wrote: Hi. Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? Mobile phones has unique challenges of being restricted in URL length etc. OpenID as it stands now has very lengthy URLs in both requests and responses and it sometimes does not fit into the restrictions. SAML world has defined artifact binding to cope with it. IMHO, OpenID should define something like that also. In Japan, there are bunch of people (including mobile carriers) who wants to do it. Are there interest here as well? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Mobile Profile?
Hi. Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? Mobile phones has unique challenges of being restricted in URL length etc. OpenID as it stands now has very lengthy URLs in both requests and responses and it sometimes does not fit into the restrictions. SAML world has defined artifact binding to cope with it. IMHO, OpenID should define something like that also. In Japan, there are bunch of people (including mobile carriers) who wants to do it. Are there interest here as well? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
There are two issues involved. 1) URL length etc. limitations 2) User interface 1) has impact on 2). For instance, we want to avoid the users pressing buttons when redirecting. And, in many cases, we do not have javascript. This means we are left with GET and this URL length limitation becomes an issue. 2) cannot be solved globally because it could very well be somewhat dependent on the carrier implementation and handset capability. For most of the phones in Japan, we can get unique id for each handset at http level fairly securely so we can depend on it to avoid any typing (not even username etc.). This was one of the factor why m-commerce got so popular in Japan. In many other markets, e.g., the U.S., this is not granted. Thus, some other means are required. I know, WIl Tan of Maleysia is working something on iPhone in this regard. Essentially, it needs to be solved per carrier or per handset class (e.g., mid-p enabled phones, etc.), I think. =nat On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: Are you talking about URL length limitations for the identifiers that users need to enter, or for URLs that are being sent around as part of the protocol? IMHO the most important question to ask for mobile devices is: can we do without typing anything? On Jan 29, 2009, at 16:56, Nat Sakimura wrote: Hi. Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? Mobile phones has unique challenges of being restricted in URL length etc. OpenID as it stands now has very lengthy URLs in both requests and responses and it sometimes does not fit into the restrictions. SAML world has defined artifact binding to cope with it. IMHO, OpenID should define something like that also. In Japan, there are bunch of people (including mobile carriers) who wants to do it. Are there interest here as well? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ 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
Re: CX proposal update
What entails the reasonable UI/UX probably depends on the jurisdiction, so we let the implimentation decide it. For example, it seems in the U.S., the agreement shown by clicking the link is acceptable while in Japan, it is not according to the METI guideline, etc. Workflow is separate from the UI. Whatever is the appropriate UI in the jurisdiction, the proof of the consent and the wrokflow (such as, if proxy signing is done, the proxy agreement must precedes the signing etc.) will probably stay the same most of the time. =nat On Fri, Jan 23, 2009 at 11:03 AM, Allen Tom a...@yahoo-inc.com wrote: Hi Nat, How will the WG define workflow and proof of user consent if the charter says that UI and UX are out of scope? Allen Nat wrote: Whether it really is legally binding depends on what jurisdiction you are in, but typically there are some minimal set of info that has to be included to be considered to be a good one. Namely, sufficiently unique identifiers for all the parties involved, term, date, expiry, renewal privision, termination clause, jurisdiction, and signatures. Signature sometimes is of not the subject but of a proxy agent. CX is going to define how these should be represented. These contracts typically lives long, and there are readability requirement as well. (I.e. it should not require a special software to read and understand what it means.) Cryptographically, it requires provisioning against algorithm getting compromised such as time stamping. We also have to define the verification procedure for all the above. Then, there is an issue of what entails the reasonable action and workflow etc. as a proof of user consent. So, in summary, while we intend to use AX (and/or OAuth hybrid) as the undelying protocol, it is a little more than merely defining another set of attributes. =...@tokyo via iPhone On 2009/01/23, at 5:43, Allen Tom a...@yahoo-inc.com wrote: Hi Nat, Can you define the term contract? Is it legally binding? It is just a signed set of attributes? Who are the parties involved with signing the contract? The RP, OP, and user? Instead of defining a new CX extension, would it just be sufficient to define new attributes using AX? Would it make more sense to use OAuth instead of defining a new OpenID extension? OAuth is designed to allow a user to authorize an RP (aka Consumer) to access protected resources hosted by the user's OP (aka Service Provider). It might make more sense to use the OpenID+OAuth hybrid protocol along with an OAuth protected web service to exchange contract information. Thanks Allen Nat Sakimura wrote: I have edited the Contract Exchange Proposal on the wiki. http://wiki.openid.net/Working_Groups%3AContract_Exchange_1 It is substantially shorter and easier to parse, hopefully. Please discuss. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- ___ specs mailing listsp...@openid.nethttp://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
CX proposal update
I have edited the Contract Exchange Proposal on the wiki. http://wiki.openid.net/Working_Groups%3AContract_Exchange_1 It is substantially shorter and easier to parse, hopefully. Please discuss. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)
I think so. =nat On Sun, Jan 11, 2009 at 8:14 AM, Breno de Medeiros br...@google.com wrote: Well, Eran published a draft of the full XRD discovery standard yesterday. That changes things, because puts discovery on much more solid ground. The biggest remaining issue to be addressed is on trust/security/signatures but there is already substantial progress on that front as well, and we can probably expect a similarly mature draft within a few weeks. Based on these developments, should we consider a commitment to do the OpenID discovery spec in time for 2.1? I think it is important to decide this early on because it affects decisions about the structure of the AuthN spec. On Tue, Jan 6, 2009 at 8:51 AM, Breno de Medeiros br...@google.comwrote: Splitting the specification will also make it easier to understand the changes between Yadis-based and XRD-based discovery, since the authN part of the spec is unlikely to change as much. I am in favor of separating the two specifications and create a 2.0-compatible (with language clean-up) version of discovery. 2009/1/6 Nat Sakimura sakim...@gmail.com: But I suppose it is worthwhile to make the spec clearler. It can be clearer by decomposeing the notion of OP into Discovery Service and Authentication Service than collectively calling it as OP. That will facilitate a better understanding of the strength and weakness of the protocol as well. =nat 2009/1/6 Drummond Reed drummond.r...@cordance.net Agreed that it makes sense to split it out when the underlying work (XRD 1.0) is ready. =Drummond From: David Recordon [mailto:drecor...@sixapart.com] Sent: Sunday, January 04, 2009 11:24 PM To: Drummond Reed Cc: sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net Subject: Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group) I'd advocate for waiting until all of the discovery work occurring in OASIS, IETF, and W3C shakes out before we make changes to how OpenID discovery works. I'd much rather make this sort of change once rather than twice. --David On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote: I'm just catching up on holiday mail and wanted to add another +1 to separation of Discovery from AuthN. The sooner the better… =Drummond From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of David Fuelling Sent: Friday, December 26, 2008 8:47 AM To: Nat Sakimura Cc: John Bradley; specs@openid.net Subject: Re: Proposal to form Discovery Working Group On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)
But I suppose it is worthwhile to make the spec clearler. It can be clearer by decomposeing the notion of OP into Discovery Service and Authentication Service than collectively calling it as OP. That will facilitate a better understanding of the strength and weakness of the protocol as well. =nat 2009/1/6 Drummond Reed drummond.r...@cordance.net Agreed that it makes sense to split it out when the underlying work (XRD 1.0) is ready. =Drummond -- *From:* David Recordon [mailto:drecor...@sixapart.com] *Sent:* Sunday, January 04, 2009 11:24 PM *To:* Drummond Reed *Cc:* sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net *Subject:* Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group) I'd advocate for waiting until all of the discovery work occurring in OASIS, IETF, and W3C shakes out before we make changes to how OpenID discovery works. I'd much rather make this sort of change once rather than twice. --David On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote: I'm just catching up on holiday mail and wanted to add another +1 to separation of Discovery from AuthN. The sooner the better… =Drummond -- *From:* specs-boun...@openid.net [mailto:specs-boun...@openid.netspecs-boun...@openid.net ] *On Behalf Of *David Fuelling *Sent:* Friday, December 26, 2008 8:47 AM *To:* Nat Sakimura *Cc:* John Bradley; specs@openid.net *Subject:* Re: Proposal to form Discovery Working Group On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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
Re: Request for consideration of Working Group Charter Proposal
+1 but where does the class in the earlier post of mine fits into in the scope? On Sat, Dec 20, 2008 at 6:16 AM, Breno de Medeiros br...@google.com wrote: siiigh. That is what senility feels like. On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom a...@yahoo-inc.com wrote: +1, but I don't know who this Tom Allen is. Allen Breno de Medeiros wrote: Attribute Exchange (1.0), and Simple Registration. II. Initial Membership * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor) * Mike Graves, mgra...@janrain.com, JanRain, Inc. * Dick Hardt, d...@skip.com. Sxip Identity. * Breno de Medeiros, br...@google.com. Google, Inc. (editor) * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications * Nat Sakimura, n-sakim...@nri.co.jp (editor) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ 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
Re: Request for consideration of Working Group Charter Proposal
I noticed a typo. Dick's mail address is not skip.com it is d...@sxip.com. =nat On Sat, Dec 20, 2008 at 11:29 AM, Nat Sakimura sakim...@gmail.com wrote: +1 but where does the class in the earlier post of mine fits into in the scope? On Sat, Dec 20, 2008 at 6:16 AM, Breno de Medeiros br...@google.comwrote: siiigh. That is what senility feels like. On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom a...@yahoo-inc.com wrote: +1, but I don't know who this Tom Allen is. Allen Breno de Medeiros wrote: Attribute Exchange (1.0), and Simple Registration. II. Initial Membership * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor) * Mike Graves, mgra...@janrain.com, JanRain, Inc. * Dick Hardt, d...@skip.com. Sxip Identity. * Breno de Medeiros, br...@google.com. Google, Inc. (editor) * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications * Nat Sakimura, n-sakim...@nri.co.jp (editor) -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Please process the WG proposals on the table (WAS The Specs Council and Process)
Well. Very good discussion. I am glad that I started the original thread. At the same time, I would like the spec council to issue overdue recommendations, especially for Contract Exchange. It has been sitting there for a long time now. (By now, the actual works should have started.) As I believe, though the scope may seems a bit wide, the WG scope being wider than what it really needs to is not a bad thing. WG can always narrow the scope without any IPR consideration, but it is virtually impossible to widen the scope afterwards. =nat -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
What is the status of AX 2.0 WG proposal?
I am very interested in it, but have not heard about it for sometime. What is the status right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Could you update me of the status of CX WG proposal?
Hi. Could you kindly update me of the status of CX WG proposal? People are waiting for it. Also, I think it is a really good idea to set up a ML for spec council so that people can mail the spec council collectively. I am emailing to David, Dick and Josh just because I happen to have found them easily in my addressbook. I wanted to email to the entire spec council, really. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: What is the status of AX 2.0 WG proposal?
I am looking foward to it! On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt dick.ha...@gmail.com wrote: Breno, if you have time to update the proposal per our discussion that would be fabulous! On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote: We have made significant process in that in-person chat and we need to document this in proposal draft form. I could try and update the proposal for validate request which has tentatively been abandoned in terms of allowing meta-data to describe attributes in fetch/store requests. 2008/12/17 Dick Hardt dick.ha...@gmail.com: I've been busy with other things. :-) I had an in person chat with Allen Tom, Eran and Breno about what they were thinking of. There was some discussion on the step2 list. I have a work item to write up the scope so that we can get it started -- but have needed to deal with some time critical tasks before I could start on it -- sorry. -- Dick On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote: I am very interested in it, but have not heard about it for sometime. What is the status right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Could you update me of the status of CX WG proposal?
Thanks Dick! I am looking forward to hear Go Ahead! from the spec council in a very near future for CX WG. =nat On Thu, Dec 18, 2008 at 11:30 AM, Dick Hardt dick.ha...@gmail.com wrote: On 17-Dec-08, at 6:17 PM, Nat Sakimura wrote: Hi. Could you kindly update me of the status of CX WG proposal? People are waiting for it. Also, I think it is a really good idea to set up a ML for spec council so that people can mail the spec council collectively. I am emailing to David, Dick and Josh just because I happen to have found them easily in my addressbook. I wanted to email to the entire spec council, really. I thought David was going to create a list for spec council. Nat: I also cc'ed Mike Jones and Johnny -- the other two members of the specs council -- Dick -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: What is the status of AX 2.0 WG proposal?
P.S. I and Hide Nara was talking the other day that it probably would be very useful for the AX to be able to define a class of attributes to define a set of attributes. For example, Creadit Card class includes following paramters: 1. FullName 2. Card Number 3. Expire Day 4. Secure digits AX parameters like this: openid.ns.ax = http://openid.net/srv/ax/2.0 openid.ax.class.card = http://visa.com/netcard/1.0 openid.ax.class.card.fullname=Bill Gate openid.ax.class.card.cardnumber = 4312 4324 5353 openid.ax.class.card.expire = 04/10 openid.ax.class.card.secure=343 Without class paremeter: openid.ns.ax = http://openid.net/srv/ax/2.0 opneid.ax.type.fullname= http://visa.com/netcard/1.0/fullname opneid.ax.type.cardnumber = http://visa.com/netcard/1.0/cardnumber opneid.ax.type.expire = http://visa.com/netcard/1.0/expire opneid.ax.type.code= http://visa.com/netcard/1.0/secure openid.ax.value.fullname=Bill Gate openid.ax.value.cardnumber = 4312 4324 5353 openid.ax.value.expire = 04/10 openid.ax.value.secure=343 With class, the message will be shorter, and also will become easier to extract a portion of the attributes in a semantically meaningful collection. We can even go on and sign over only one class etc. Could we add something like this to the scope as well? =nat On Thu, Dec 18, 2008 at 1:00 PM, Nat Sakimura sakim...@gmail.com wrote: I am looking foward to it! On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt dick.ha...@gmail.com wrote: Breno, if you have time to update the proposal per our discussion that would be fabulous! On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote: We have made significant process in that in-person chat and we need to document this in proposal draft form. I could try and update the proposal for validate request which has tentatively been abandoned in terms of allowing meta-data to describe attributes in fetch/store requests. 2008/12/17 Dick Hardt dick.ha...@gmail.com: I've been busy with other things. :-) I had an in person chat with Allen Tom, Eran and Breno about what they were thinking of. There was some discussion on the step2 list. I have a work item to write up the scope so that we can get it started -- but have needed to deal with some time critical tasks before I could start on it -- sorry. -- Dick On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote: I am very interested in it, but have not heard about it for sometime. What is the status right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: A Working Groups Wiki Page
Indeed. From the spec works point of view, since a WG can always narrow the scope but not exand, it would be better to get it in the scope at the beginning. That's why I have put it there. We can always drop it later. =nat On Fri, Dec 5, 2008 at 10:14 AM, Breno de Medeiros br...@google.com wrote: On Thu, Dec 4, 2008 at 5:00 PM, Nat Sakimura sakim...@gmail.com wrote: Hi Breno, I am hoping that the core spec will define public key based signature. If it is done, CX is going to use it. Dsig thing in the CX proposal is there just for the sake if it did not make it into the core spec because it absolutely is a MUST for CX. (Although, from the modularity point of view, it might be better to define dsig separately and reference it from the core spec.) As long as you are aware of the issue, you can tackle this at a latter point by how you structure your deliverables. =nat On Fri, Dec 5, 2008 at 2:20 AM, Breno de Medeiros br...@google.com wrote: Hi Nat, I see that as part of your scope you are discussing an OpenID D-Sign deliverable. Is this really necessary? For instance, the XRD 1.0 spec (which at this point is planned for incorporation into the OpenID spec by reference) will introduce a signature scheme for trust purposes. That will mean that a a D-Sig algorithm will be part of the core spec. There is also some speculation that OpenID will support OAuth style signatures (which include a public-key variant) for harmonization. If that happens there would be _two_ public-key signature schemes as part of the core spec. I understand the public-key signatures is a core requirement for a trust specification. But I doubt there is a reason to re-invent such a scheme. Signature schemes are supposed to be somewhat generic, not purpose-specific. We should try to specify only a few of them, and probably the place to do that is the core OpenID spec. 2008/12/4 Nat Sakimura sakim...@gmail.com: Thanks David, I have put the CX page onto it. Regards, =nat On Thu, Dec 4, 2008 at 4:40 PM, David Recordon drecor...@sixapart.com wrote: We now have a wiki page for Working Groups! http://wiki.openid.net/Working_Groups I've listed the current PAPE WG as well as the groups that I know have been proposed. I've also filled in the draft charter for the Auth 2.1 group at http://wiki.openid.net/Working_Groups:Auth_2.1. If you're wanting to see a WG happen, please take this time to fill in it's draft charter so that members of this list can review it. My goal would be to have all four of the proposed groups ready to be voted on by the Foundation Membership during the same period as the Board election -- one week from today -- so that they can all be created within the next two weeks. If you need help writing a charter, I'm happy to help. --David ___ 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
P.S., Nine things in the scope does not correspond to the deliverables. It merely indicates that these things need to be addressed. P.P.S. Having stated above, after our evaluation, it boiled down to 4 deliverables. I have created the wiki page for it. Please refer to it as the most current version of the charter proposal. http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0 Hope this one is finally acceptable. On Thu, Dec 4, 2008 at 10:42 PM, Nat Sakimura [EMAIL PROTECTED] wrote: I have discussed with Dick at iiw to see if it is possible to build on AX. It seems it is inevitable that there needs to be some modifications/extensions to AX if it is to be done on AX. We at NRI and Mike of JanRain have been evaluating what is needed since I submit the last version of the charter and we are coming close to the conclusion on what is needed. In essence, we need to add another message type apart from fetch and store to AX, and we need to define the direct communication in both directions (OP-RP and RP-OP). If it is done, we are quite confident that we can build the CX on top of AX. In conjunction with it, I have been working on XRD SimpleSign that it depends on. We are still working out the details, but that probably should be the topic of the WG to follow up. I am going to post the amended charter to the Wiki. Also, I think it is a good practice to formalize the message acceptance note issuing procedure (well, the workflow in general) so that there will not be a proposal which is not being dealt with. Regards, =nat On Thu, Dec 4, 2008 at 4:52 PM, David Recordon [EMAIL PROTECTED]wrote: Hi Nat,Mike Jones just pointed out that the Steward Council hadn't yet caught this email which I apologize for. I have two concerns with this charter: 1) It appears the WG is going to deliver 9 specifications with a list that isn't clear about what each specification will do and how they relate. Past approved WG proposals (as well as the current drafts) have had a very clear set of deliverables. 2) While discussed heavily at IIW, this proposal still does not clearly seem build on top of the AX specification. The current OpenID specifications very clearly fit together and build atop each other and this one should be no different. I'm working on figuring out how to have the Stewards Council recommendation created on a public mailing list, but felt it worthwhile to share my opinions here until that happens. --David On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote: I was pointed out by Dick that Key Exchnage really should be Key Discovery. I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura [EMAIL PROTECTED] wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat *Contract Exchange WG Charter (formally TX). * In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: *Proposal*: (a) *Charter*. (i) *WG name*: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) *Purpose*: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enable s arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) *Scope*: Scope of the work -Development of the specifications including: - Public Key Exchange method - A Public Key Cryptography based digital signature method. - Legally binding contract format. - Query/response communication protocols for establishing and canceling of the contract. - Message Encryption method to be used for the relevant communications. - Notification interface for asynchronous communications. - Possible extension and profiling of [AX] to accommodate the above. - Provisions for long term storage of the contracts. - Conformance requirements for other data transfer protocol bindings - Security, threats and Risk analysis - Perform Security Risk analysis
Re: A Working Groups Wiki Page
Thanks David, I have put the CX page onto it. Regards, =nat On Thu, Dec 4, 2008 at 4:40 PM, David Recordon [EMAIL PROTECTED]wrote: We now have a wiki page for Working Groups! http://wiki.openid.net/Working_Groups I've listed the current PAPE WG as well as the groups that I know have been proposed. I've also filled in the draft charter for the Auth 2.1 group at http://wiki.openid.net/Working_Groups:Auth_2.1. If you're wanting to see a WG happen, please take this time to fill in it's draft charter so that members of this list can review it. My goal would be to have all four of the proposed groups ready to be voted on by the Foundation Membership during the same period as the Board election -- one week from today -- so that they can all be created within the next two weeks. If you need help writing a charter, I'm happy to help. --David ___ 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
Re: A Working Groups Wiki Page
Hi Breno, I am hoping that the core spec will define public key based signature. If it is done, CX is going to use it. Dsig thing in the CX proposal is there just for the sake if it did not make it into the core spec because it absolutely is a MUST for CX. (Although, from the modularity point of view, it might be better to define dsig separately and reference it from the core spec.) =nat On Fri, Dec 5, 2008 at 2:20 AM, Breno de Medeiros [EMAIL PROTECTED] wrote: Hi Nat, I see that as part of your scope you are discussing an OpenID D-Sign deliverable. Is this really necessary? For instance, the XRD 1.0 spec (which at this point is planned for incorporation into the OpenID spec by reference) will introduce a signature scheme for trust purposes. That will mean that a a D-Sig algorithm will be part of the core spec. There is also some speculation that OpenID will support OAuth style signatures (which include a public-key variant) for harmonization. If that happens there would be _two_ public-key signature schemes as part of the core spec. I understand the public-key signatures is a core requirement for a trust specification. But I doubt there is a reason to re-invent such a scheme. Signature schemes are supposed to be somewhat generic, not purpose-specific. We should try to specify only a few of them, and probably the place to do that is the core OpenID spec. 2008/12/4 Nat Sakimura [EMAIL PROTECTED]: Thanks David, I have put the CX page onto it. Regards, =nat On Thu, Dec 4, 2008 at 4:40 PM, David Recordon [EMAIL PROTECTED] wrote: We now have a wiki page for Working Groups! http://wiki.openid.net/Working_Groups I've listed the current PAPE WG as well as the groups that I know have been proposed. I've also filled in the draft charter for the Auth 2.1 group at http://wiki.openid.net/Working_Groups:Auth_2.1. If you're wanting to see a WG happen, please take this time to fill in it's draft charter so that members of this list can review it. My goal would be to have all four of the proposed groups ready to be voted on by the Foundation Membership during the same period as the Board election -- one week from today -- so that they can all be created within the next two weeks. If you need help writing a charter, I'm happy to help. --David ___ 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
I was pointed out by Dick that Key Exchnage really should be Key Discovery. I agree. So, I would do s/Key Exchange/Key Discovery/g. Cheers, =nat On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura [EMAIL PROTECTED] wrote: Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat *Contract Exchange WG Charter (formally TX). * In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: *Proposal*: (a) *Charter*. (i) *WG name*: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) *Purpose*: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enable s arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) *Scope*: Scope of the work -Development of the specifications including: - Public Key Exchange method - A Public Key Cryptography based digital signature method. - Legally binding contract format. - Query/response communication protocols for establishing and canceling of the contract. - Message Encryption method to be used for the relevant communications. - Notification interface for asynchronous communications. - Possible extension and profiling of [AX] to accommodate the above. - Provisions for long term storage of the contracts. - Conformance requirements for other data transfer protocol bindings - Security, threats and Risk analysis - Perform Security Risk analysis and profiles for best practice Out of scope - Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. - Assurance programs or other identity governance frameworks. - It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) *Proposed* List of Specifications: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 2009. (v) *Anticipated audience or users of the work*: Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) *Language* in which the WG will conduct business: English. (vii) *Method of work*: E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to-face meetings at conferences. (viii) *Basis for determining when the work of the WG is completed*: Drafts will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the drafts has been achieved, consistent with the purpose and scope. (b) *Background Information*. (i) Related work being done by other WGs or organizations: - OpenID Attribute Exchange Extension 1.0 [AX]http://openid.net/specs/openid-attribute-exchange-1_0.html - LIberty Alliance Identity Governance Framework [IGF] 1.0 Drafthttp://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip - *XML Advanced Electronic Signatures [XAdES]* - WS-Trust 1.3 [WS-trust] http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc - XRI 2.0 [XRI] - XDI 1.0 [XDI] - Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED
Re: Proposal to create the TX working group
Hi. Here is the modified version of the charter based on the discussion at IIW. I chose Contract Exchange instead of Contract Negotiation since detailed negotiation is out of scope. Cheers, =nat *Contract Exchange WG Charter (formally TX). * In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: *Proposal*: (a) *Charter*. (i) *WG name*: Contract Exchange WG (formally Trust Exchange Extension (TX)) (ii) *Purpose*: The purpose of this WG is to produce a series of standard OpenID extension to the OpenID Authentication protocol that enablesarbitrary parties to create and exchange a mutually-digitally-signed legally binding contract that are both broadband and mobile friendly by defining appropriate bindings for each use case. For this purpose, (1) public key exchange, (2) signed request and response based on the public keys, (3) content encryption based on public key, (4) extensible data transfer method, (5) contract format, (6) notification methods for asynchronous communications are needed to be defined. For this purpose, this WG will explorer the possibility of using/extending OpenID Attribute Exchange [AX] as well as defining new extensions where it may fit. (iii) *Scope*: Scope of the work -Development of the specifications including: - Public Key Exchange method - A Public Key Cryptography based digital signature method. - Legally binding contract format. - Query/response communication protocols for establishing and canceling of the contract. - Message Encryption method to be used for the relevant communications. - Notification interface for asynchronous communications. - Possible extension and profiling of [AX] to accommodate the above. - Provisions for long term storage of the contracts. - Conformance requirements for other data transfer protocol bindings - Security, threats and Risk analysis - Perform Security Risk analysis and profiles for best practice Out of scope - Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. - Assurance programs or other identity governance frameworks. - It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) *Proposed* List of Specifications: Sries of specs encompassing the above requirements. The actual spec may happened to be just an expansion of AX or several news specs as it will be determined in the WG. Expected completion of the first iteration is in Q1 2009. (v) *Anticipated audience or users of the work*: Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) *Language* in which the WG will conduct business: English. (vii) *Method of work*: E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to-face meetings at conferences. (viii) *Basis for determining when the work of the WG is completed*: Drafts will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the drafts has been achieved, consistent with the purpose and scope. (b) *Background Information*. (i) Related work being done by other WGs or organizations: - OpenID Attribute Exchange Extension 1.0 [AX]http://openid.net/specs/openid-attribute-exchange-1_0.html - LIberty Alliance Identity Governance Framework [IGF] 1.0 Drafthttp://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip - *XML Advanced Electronic Signatures [XAdES]* - WS-Trust 1.3 [WS-trust] http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc - XRI 2.0 [XRI] - XDI 1.0 [XDI] - Vendor Relationship Management [VRM] (ii) Proposers: Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan) John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada) Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.) Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.(Japan) Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland) Tatsuki Sakushima
Re: Proposal to create the TX working group
Whether to include these amt.* in it as a generic item or not is what is needed to be discussed in the WG, I think. I have thrown those in as in most contracts these are needed. (Note: unit does not have to be a monetary one.) As a summary value, in the actual transactions, they happen to be pretty useful. As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use XRDS based trusted discovery + ID-WSF (preferably RESTful version) rather than OpenID because it implies that you have SAML processor including XMLEncryption and XMLSig (which seems to hinder the adoption right now in many scripting language.) TX as it stands now is trying to avoid this issue by being purely tag-value based. Also, it is trying to be mobile friendly, which is kind of hard with AX partly because of its extensibility feature. Having said that, I think it is important to be able to translate TX message to SAML ro WS-Trust based messages for the harmonization reason. Whether it has a future or not is not something a spec writer should determine, but it is something that the market should determine, IMHO. Is there an example of AX+SAML deployed and making transaction of monetary value right now or in the near future? An earlier version of TX is doing millions of dollars right now and is set to expand in the coming years (hopefully quite drastically.) You can start guessing by looking at the member list of OpenID Japan (note: not all of them are in the list. Some of them are still in process, and some of them would not like to be identified.) and why some peculiar variables are defined in the proposed TX spec. =nat On Sun, Nov 9, 2008 at 4:29 PM, David Recordon [EMAIL PROTECTED]wrote: After reading the extension a few times, I'm getting caught up in 4.1.6 ( http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7)http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7%29which references amounts being paid, currency, contracts, terms of the contract, etc. Overall, I'm pretty confused about what this extension does (it seems to do a lot of different things) which is making it hard for me to determine a better name. I also still feel that the reuse of AX (for it's extensibility) combined with the ability to exchange signed SAML tokens is a more future proof method and something that will be easier to be widely adopted as OpenID continues to evolve. --David On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote: +1. OpenID Trust Extension seems like a good fit. =Drummond -- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED][EMAIL PROTECTED] ] *On Behalf Of *Nat Sakimura *Sent:* Saturday, November 08, 2008 12:22 PM *To:* [EMAIL PROTECTED] *Cc:* specs@openid.net *Subject:* Re: Proposal to create the TX working group Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura [EMAIL PROTECTED] wrote: Hi David, I do not have any particular attachment to trust exchange. So, I am ok in changing it but it would be nice if I can preserve TX acronym though. Do you have any specific suggestions? =nat On Sun, Nov 9, 2008 at 3:50 AM, David Recordon [EMAIL PROTECTED] wrote: Hi Nat, Thanks. I still would really like to see the name changed for when we think about the World-wide market. Do others disagree? OpenID Trust Exchange just feels like it doesn't actually describe what the spec does nor how you can actually exchange trust. --David On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote: Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon [EMAIL PROTECTED] Hey Nat, Do you see this as being built atop Attribute Exchange for transport or as something new that TX defines? I know Sxip had done work with AX to enable passing signed and encrypted attributes using SAML assertions. I have thought of using AX as transport once, then gave up on it when I was thinking of a mobile use case where the amount of payload that could be carried with was very limited (URL length in GET is limited to one of 128bytes, 256bytes or 512bytes depending on the handset). So, the current draft looks a lot like AX with bunch of hard coded attribute types in a way. As far as carrying SAML token etc. in AX are concerned, similar thing has also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak of Estonia (openid.ee) has been using XAdES with AX. These approach are valid. However, I thought the approach partly defeats the purpose of OpenID. If we were using SAML, then we could have used it through out. I wanted to make it easier for the developers by sticking to the tag-value approach. This made us define some of the attribute types defined in SAML and XAdES to be defined as tag-value tag. Is Trust
Re: Proposal to create the TX working group
Maybe just OpenID Trust Extension just like WS-Trust? =nat On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura [EMAIL PROTECTED] wrote: Hi David, I do not have any particular attachment to trust exchange. So, I am ok in changing it but it would be nice if I can preserve TX acronym though. Do you have any specific suggestions? =nat On Sun, Nov 9, 2008 at 3:50 AM, David Recordon [EMAIL PROTECTED]wrote: Hi Nat,Thanks. I still would really like to see the name changed for when we think about the World-wide market. Do others disagree? OpenID Trust Exchange just feels like it doesn't actually describe what the spec does nor how you can actually exchange trust. --David On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote: Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon [EMAIL PROTECTED] Hey Nat,Do you see this as being built atop Attribute Exchange for transport or as something new that TX defines? I know Sxip had done work with AX to enable passing signed and encrypted attributes using SAML assertions. I have thought of using AX as transport once, then gave up on it when I was thinking of a mobile use case where the amount of payload that could be carried with was very limited (URL length in GET is limited to one of 128bytes, 256bytes or 512bytes depending on the handset). So, the current draft looks a lot like AX with bunch of hard coded attribute types in a way. As far as carrying SAML token etc. in AX are concerned, similar thing has also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak of Estonia (openid.ee) has been using XAdES with AX. These approach are valid. However, I thought the approach partly defeats the purpose of OpenID. If we were using SAML, then we could have used it through out. I wanted to make it easier for the developers by sticking to the tag-value approach. This made us define some of the attribute types defined in SAML and XAdES to be defined as tag-value tag. Is Trust Exchange really the best name? Seems like trust is quite a broad concept so something more specific might be better. Right. Naming was a bit problematic. I started using Trust because the messaging model is not dis-similar to WS-Trust. Now, the trust defined in WS-Trust in our context is essentially Contract. So I thought of changing it to CX or something, but then, at least in Japan, quite a few key people were already exposed to TX by now and thus I kept the name TX. --David On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote: Dear Specification Council members: In accordance with the OpenID Foundation IPR policies and procedureshttp://openid.net/foundation/intellectual-property/this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: ** *Trust Exchange (TX) Extension WG Charter* In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Trust Exchange Extension (TX) (ii) Purpose: The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract. This protocol extension aims to be both broadband and mobile friendly by defining appropriate bindings for each use case. Although this specification defines one default protocol for transfering data based on the contract, the data transfer portion is intended to be pluggable so that other protocols may also be used for this purpose. The extension is not intended to be a general method for defining attributes; the scope is limited to a specific set of attributes necessary for contract semantics. The extension will also define a contract signature based on public key cryptography. When used with a digital certificate signed by a third party, the contract and signature can be used as an assertion of conformance to an applicable assurance program. (iii) Scope: Scope of the work -Development of the specification including: - An extensible tag-value contract format - Public Key Cryptography based digital signature method applied to the above contract format - Query/response communication protocols for establishing the contract - Default data transfer protocol based on the contract - Conformance requirements for other data transfer protocol bindings - Security, threats and Risk analysis - Perform Security Risk analysis and profiles for best practice Out of scope - Term negotiation: Actual negotiation of the terms of a contract
Re: Proposal to create the TX working group
Hi David, Thanks for your comments. My reply inline below: 2008/11/1 David Recordon [EMAIL PROTECTED] Hey Nat,Do you see this as being built atop Attribute Exchange for transport or as something new that TX defines? I know Sxip had done work with AX to enable passing signed and encrypted attributes using SAML assertions. I have thought of using AX as transport once, then gave up on it when I was thinking of a mobile use case where the amount of payload that could be carried with was very limited (URL length in GET is limited to one of 128bytes, 256bytes or 512bytes depending on the handset). So, the current draft looks a lot like AX with bunch of hard coded attribute types in a way. As far as carrying SAML token etc. in AX are concerned, similar thing has also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak of Estonia (openid.ee) has been using XAdES with AX. These approach are valid. However, I thought the approach partly defeats the purpose of OpenID. If we were using SAML, then we could have used it through out. I wanted to make it easier for the developers by sticking to the tag-value approach. This made us define some of the attribute types defined in SAML and XAdES to be defined as tag-value tag. Is Trust Exchange really the best name? Seems like trust is quite a broad concept so something more specific might be better. Right. Naming was a bit problematic. I started using Trust because the messaging model is not dis-similar to WS-Trust. Now, the trust defined in WS-Trust in our context is essentially Contract. So I thought of changing it to CX or something, but then, at least in Japan, quite a few key people were already exposed to TX by now and thus I kept the name TX. --David On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote: Dear Specification Council members: In accordance with the OpenID Foundation IPR policies and procedureshttp://openid.net/foundation/intellectual-property/this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: ** *Trust Exchange (TX) Extension WG Charter* In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Trust Exchange Extension (TX) (ii) Purpose: The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract. This protocol extension aims to be both broadband and mobile friendly by defining appropriate bindings for each use case. Although this specification defines one default protocol for transfering data based on the contract, the data transfer portion is intended to be pluggable so that other protocols may also be used for this purpose. The extension is not intended to be a general method for defining attributes; the scope is limited to a specific set of attributes necessary for contract semantics. The extension will also define a contract signature based on public key cryptography. When used with a digital certificate signed by a third party, the contract and signature can be used as an assertion of conformance to an applicable assurance program. (iii) Scope: Scope of the work -Development of the specification including: - An extensible tag-value contract format - Public Key Cryptography based digital signature method applied to the above contract format - Query/response communication protocols for establishing the contract - Default data transfer protocol based on the contract - Conformance requirements for other data transfer protocol bindings - Security, threats and Risk analysis - Perform Security Risk analysis and profiles for best practice Out of scope - Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. - General purpose data type identifiers: this should be determined on a per-community bases using other specifications such as OpenID Attribute Exchange. - Assurance programs or other identity governance frameworks. - It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) Proposed List of Specifications: TX 1.0, spec completion expected in January 2009. (v) Anticipated audience or users
Proposal to create the TX working group
Dear Specification Council members: In accordance with the OpenID Foundation IPR policies and procedures http://openid.net/foundation/intellectual-property/ this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: ** *Trust Exchange (TX) Extension WG Charter* In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Trust Exchange Extension (TX) (ii) Purpose: The purpose of this WG is to produce a standard OpenID extension to the OpenID Authentication protocol that enables arbitrary parties to create and exchange a mutually-digitally-signed legally binding contract. This protocol extension aims to be both broadband and mobile friendly by definingappropriatebindings for each use case. Although this specification defines one default protocol for transfering data based on the contract, the data transfer portion is intended to be pluggable so that other protocols may also be used for this purpose. The extension is not intended to be a general method for defining attributes; the scope is limited to a specific set of attributes necessary for contract semantics. The extension will also define a contract signature based on public key cryptography. When used with a digital certificate signed by a third party, the contract and signature can be used as an assertion of conformance to an applicable assurance program. (iii) Scope: Scope of the work * Development of the specification including: o An extensible tag-value contract format o Public Key Cryptography based digital signature method applied to the above contract format o Query/response communication protocols for establishing the contract o Default data transfer protocol based on the contract o Conformance requirements for other data transfer protocol bindings * Security, threats and Risk analysis o Perform Security Risk analysis and profiles for best practice Out of scope * Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. * General purpose data type identifiers: this should be determined on a per-community bases using other specifications such as OpenID Attribute Exchange. * Assurance programs or other identity governance frameworks. * It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) Proposed List of Specifications: TX 1.0, spec completion expected in January 2009. (v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to-face meetings at conferences. (viii) Basis for determining when the work of the WG is completed: Draft 1 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: * LIberty Alliance Identity Governance Framework (IGF) 1.0 Draft http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip * XML Advanced Electronic Signatures (XAdES) http://www.w3.org/TR/XAdES/ (ii) Proposers: Drummond Reed, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Tact Communications (Japan) John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada) Mike Graves, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], JanRain, Inc. (U.S.A.) Nat Sakimura, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Nomura Research Institute, Ltd.(Japan) Robert Ott, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], Clavid (Switzerland) Tatsuki Sakushima, [EMAIL
Re: Backporting the 2.0 extension mechanism to 1.1
Since PAPE needs more integrity in the message (otherwise, the whole point of PAPE is lost), it would be ok to leave it just to OpenID 2.0 and make it an incentive to move to OpenID 2.0, IMHO. =nat Johnny Bufu wrote: On 11/08/08 10:35 AM, Martin Atkins wrote: In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. You're right - my brain must have left out the portion you emphasized, since it didn't use to be there. I thought PAPE was not meant to be compatible with 1.1, exactly for the reasons you outlined in the initial message. Not sure what the best approach would be here: specify how PAPE could be used with OpenID 1.1, or leave it as an incentive to upgrade to 2.0. Johnny ___ 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: Backporting the 2.0 extension mechanism to 1.1
Actially, that interpretation is not right. In draft 3, we have made it clear. [EMAIL PROTECTED] On 2008/08/12, at 2:35, Martin Atkins [EMAIL PROTECTED] wrote: Johnny Bufu wrote: On 11/08/08 12:49 AM, Martin Atkins wrote: I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the pape prefix on its arguments. Where/how? To my knowledge the opposite is true, per the last paragraph here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3 In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. ___ 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: Non-interactive logins
The implementation we have done at JAL is composed of the following: 1) Normal OpenID Auth 2.0 procedure 2) Extention to hook contract negotiation upon OpenID Auth 2.0 procedure 3) Actual Contract and back channel data transfer protocol negotiation. 4) Actual data transfer. For 2) and 3) above, the service provider issues a signed contract proposal, and the end user is shown the terms and conditions. If end user agrees to it or part of it, the term is finalized and counter signed, and its URL is sent back with OpenID authentication response. This contract gives non-repudiation to the parties. There after, the service provider can use the contract to retrive the desired data as par specified in the contract. The data transfer protocol can be anything. It can be OAuth, ID-WSF or something else, which should be specified in the contract. (Does not have to be: if the data acqusition URL can expose XRDS and publicise the available data transfer protocols, it can be done dynamically.) It was first reviewd at iiw2007b and the basic flow has been on the OpenID wiki for sometime: http://wiki.openid.net/Trusted_Data_Exchange , though it is a bit out of date. Also, the name Trusted Data Exchange, but the name is not quite depictive, so, it probably should be decomposed into Contract Negotiation, and something else. Note that this system has been live since the end of May this year, in the real transaction of monetary value. I do plan to propose it as the WG in the coming weeks. If you would like to join in the boat, you are more than welcome :-) =nat Anders Feder wrote: tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer: And of course any number of extensions could be created to obtain an access token via an alternate path, after which normal OAuth can be used. Sure, but isn't this equally true for OpenID? If that is the case, I would like to ask the list if anybody is interested in working towards such an extension. Joseph Holsten pointed me to Appendix A of the OAuth specification for an example. In step A.3, The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos. Also, OAuth appears to be more about authorization (to access a remote resource) than about authentication. Is there any way to operate either OpenID or OAuth entirely non-interactively? tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton: Hi Anders, You might want to check out OAuth ... it was developed for just such a situation. - Scott On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote: Hello, There have been some discussion over the years about using OpenID for non-interactive logins. Can someone kindly tell me what the status is of this feature? In particular login from non-browser applications - is this currently possible (e.g. using client certificate authentication)? Thanks. -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Anders Feder [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. XDI.ORG Vice Chair ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the PAPE working group
Perhaps you could explain to the list what the process will be after this, such as: 1) Specification Council to approved PAPA WG. 2) Call for Participation ... etc. IMHO, that will help the community to understand the process a lot. By the way, I plan to respond to 2) above. I could have been a proposer of the WG, but to debug the process, somebody has to do the role of responder to the call for participation, so... :-) =nat 2008/5/23 Mike Jones [EMAIL PROTECTED]: This message is being sent to revise the proposal to create the PAPE working group, changing only one word, so that the projected completion date is July 2008, rather than May 2008. The complete text of the revised proposal follows. --- Mike In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Proposal: (a) Charter. (i) WG name: Provider Authentication Policy Extension (PAPE) (ii) Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that: provides a mechanism by which a Relying Party can request that particular authentication policies be applied by the OpenID Provider when authenticating an End User and provides a mechanism by which an OpenID Provider may inform a Relying Party which authentication policies were used. Thus a Relying Party can request that the End User authenticate, for example, using a phishing-resistant and/or multi-factor authentication method. (iii) Scope: Produce a revision of the PAPE 1.0 Draft 2 specification that clarifies its intent, while maintaining compatibility for existing Draft 2 implementations. Adding any support for communicating requests for or the use of specific authentication methods (as opposed to authentication policies) is explicitly out of scope. (iv) Proposed List of Specifications: Provider Authentication Policy Extension 1.0, spec completion expected during July 2008. (v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties – especially those interested in mitigating the phishing vulnerabilities of logging into OpenID providers with passwords. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly a face-to-face meeting at the Internet Identity Workshop. (viii) Basis for determining when the work of the WG is completed: Proposed changes to draft 2 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done in other WGs or organizations: (1) Assurance Levels as defined by the National Institute of Standards and Technology (NIST) in Special Publication 800-63 (Burr, W., Dodson, D., and W. Polk, Ed., Electronic Authentication Guideline, April 2006.) [NIST_SP800‑63]. This working group is needed to enable authentication policy statements to be exchanged by OpenID endpoints. No coordination is needed with NIST, as the PAPE specification uses elements of the NIST specification in the intended fashion. (ii) Proposers: Michael B. Jones, [EMAIL PROTECTED], Microsoft Corporation David Recordon, [EMAIL PROTECTED], Six Apart Corporation Ben Laurie, [EMAIL PROTECTED], Google Corporation Drummond Reed, [EMAIL PROTECTED], Cordance Corporation John Bradley, [EMAIL PROTECTED], Wingaa Corporation Johnny Bufu, [EMAIL PROTECTED], Independent Dick Hardt, [EMAIL PROTECTED], Sxip Identity Corporation Editors: Michael B. Jones, [EMAIL PROTECTED], Microsoft Corporation David Recordon, [EMAIL PROTECTED], Six Apart Corporation (iii) Anticipated Contributions: None. ___ 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
Re: Login Federation
Actually, there seems to be. I was reading through the documents today and found about it. http://openid.net/ipr/OpenID_Process_Document_(Final_Clean_20071221).pdf Basically, 1. Contributors for the new spec Sign the Contribution Agreement and gather more than five proposed WG members. 2. Apply for a new Work Group to specs@openid.net = This needs to fulfil certain requirement. 3. Get the approval from the Specification Council which is composed of two board members and five current and ex-editors (“Eligible Editors). Who are the members of the current Specification Council? 4. Start WG. Spec needs to go through three stages process: Draft - Implementors Draft - Final Basically, WG needs concensus to propose the spec to be implementors draft etc. to the members.After certain review period, members get to vote. The quorum is greater of 20% of OIDF members or 20 OIDF members. Regards, =nat Brett Carter wrote: John Ehn wrote: Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments. Thanks! Is there a formal process for submitting a proposal yet? Or are we just going with RFC format for now? -Brett ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Login Federation
In a single domain scenario, such as inside a corporation, one could issue a domain cookies having op_identifier or claimed_id and RP can start the authentication request based on this. It is not in the spec, but can easily be done. In a multi domain scenario such as the Internet, it is not that simple. If the sites are in a same Circle of trust, then they can set up a shared server with multiple domain names and issue identical domain cookie a la Liberty. This is essential the same as the single domain scenario, then. This again is not in the spec. If this is not desired or possible, things does not work out so nicely then. You need a way to tell RP the OP somehow. One possible way is always to jump from a link page but that is not very realistic. Using a browser plug-in is another. Of course, this is not a spec either... Regards, Nat Brett Carter wrote: 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 -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
Hi. For 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. like it was mentioned before PAPE does some job, and AQE does some other. Of course, that is only the claim that OP makes, so there has to be some kind of trust framework, where I belive that reputation comes in. 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. Simple way of doing this is white list. Many does this already. More dynamic one would use Reputation Service. Reputation Service would be another (sort of ) extention, IMHO. On the reputation, I wrote a bit on my blog, so you may want to read it as well. http://www.sakimura.org/en/modules/wordpress/index.php?p=30 Re: OpenID 3.0 While we were writing (are still writing) OpenID Trusted data Exchange (TX) proposal, we started to feel that if we introduce Reputation Service appropreately, we can skip the association and check_authentication entirely. If this kind of change would make the protocol faster and more secure, we perhaps can start considering it in the core spec., but otherwise, they should be done as extension spec. Rule of the thumb perhaps is that unless we need to touch / change the basic flow of the core protocol, we do not need to go to 3.0. Regards, =nat Johannes Ernst wrote: Amen. Let's build (optional) extensions, and only if that absolutely does not work for an essential feature, meekly suggest that the smallest possible set of changes be made to an existing spec. Note that any term such as OpenID 3.0 is mostly a marketing / branding term, just like OpenID 2.0. What it really means is what underlying specs are being packaged into a larger term. On Feb 2, 2008, at 2:36, Martin Atkins wrote: I apologise that this message doesn't directly address any of the points you've made, but others have been doing that. I just want to make a general point: In my opinion, we should resist the urge to start specing OpenID 3.0 (aka OpenID vNext) and try to do everything else that needs to be done with extensions now. OpenID 2.0 has laid the framework for decentralized extensibility, so it should now be much easier to work within that framework. 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. McGovern, James F (HTSC, IT) 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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XACML
Hi James, I am definitely interested in something like that. It has been a long standing ToDo for me, though currently, my focus is more on the reputation side because I need it now for an implementation that we are doing now (for enterprise use.) Nat Bill Washburn wrote: 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) On Dec 11, 2007 9:31 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 mailto:specs@openid.net http://openid.net/mailman/listinfo/specs http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [Idschemas] identity schema element metadata: using existingspecifications
Hi, Instead of having one single master copy at the IdP, I would prefer one single piece of each information disparsed over the network (optionally with opaque identifiers) and having IdP managing the links so that I can control all the pieces from one place. I feel that having everything at one place is too risky. =nat Chris Drake wrote: Hi, Having missed the summit - can anyone tell if there was any dissent or scaremongering going on? The idea of assisting everyone who's collecting information about me, to share it easily, seems like an exceptionally Bad Idea (tm). If anyone's building anything that assists these companies to give up or relinquish their collection of my data, in favor of letting me hold the one single master copy if it myself, on my chosen IdP, and to let me arbitrate who can use it, when, and how - now *that* would be something to congratulate people about. Search google/google-news for paper shredder ... Kind Regards, Chris Drake, =1id.com Saturday, September 8, 2007, 5:33:20 PM, you wrote: DR Mark, DR I just wanted to say that based on what I learned about them at the Data DR Sharing Summit (http://datasharingsummit.com) today, and what I read on my DR first pass tonight, these are fine pieces of work that really push the ball DR forward. DR Hats off to you. DR =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:idschemas- [EMAIL PROTECTED] On Behalf Of Mark Wahl Sent: Thursday, September 06, 2007 6:05 PM To: ID Schemas Cc: OpenID specs list Subject: [Idschemas] identity schema element metadata: using existingspecifications I'm reformatting the table of identity schema metadata, located at http://idschemas.idcommons.net/moin.cgi/MetaData, into a pair of more compact and usable specifications. One spec describes where the existing well-known metadata (e.g., Dublin Core) should be used when describing identity schemas and their schema elements (i.e., attribute types and claim types). The other spec will describe how to represent identity schema metadata for which there is no pre-existing well-known specification. I've attached a copy of the first draft of the Identity Schema Element Metadata: Using Existing Specifications. Mark Wahl Informed Control Inc. DR ___ DR specs mailing list DR specs@openid.net DR http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Public key idea is somewhat attractive to me, but there are some issues that comes up in my mind as well. 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. 2) It may mean a high cost operation for OPs. If we do this, it makes OP operation very high cost because to make the service safe, it would require a lot of measures. (NRI is providing similar kind of service but it indeed is very high cost operation.) Nice thing about i-number is that it has no value like public key except for its resolvability. Even if it leaks, that's kind of ok so operational risk is low. Actually, these private key pain may be eased by IBE (Identity Based Encryption) but I need some more time to contemplate on it. 3) Since OPs has an access to the users' private key, they may recycle them as well. IMHO, recycling is operational problem as well as a technical one. i-number from a certified i-broker is somewhat trustable on the account of no recycling because of this operational restriction. Could there be operational restriction similart to that for general OPs as well? =nat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Thursday, May 31, 2007 2:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
