Re: Promoting OpenID
On Apr 5, 2007, at 18:36, Chris Messina wrote: ... I personally think selling to the enterprise is nearly impossible without tons of grassroots adoption ... I disagree. ;-) Now granted, there are many, many things that we all need to do and that need to happen to make OpenID suitable for the enterprise market on a "mass" market basis. People like James keep reminding us of that on this list and in other places, and please keep it coming. But it's definitely not the case any more that it is "impossible"... Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Promoting OpenID
I thought it was interesting to discover this: http://www.atlassian.com/software/crowd/ On the one hand, this is interesting from a marketing perspective, and I think we need more education materials and demonstrations of how this technology can be used. On the other, I personally think selling to the enterprise is nearly impossible without tons of grassroots adoption (think: Firefox) who will their feet to the fire, at which point, we can tell them that we have a bucket of water called OpenID that they can implement to alleviate the burn. But that's just how I roll. :) Chris On 4/4/07, Wes Kussmaul <[EMAIL PROTECTED]> wrote: > > > As long as we're being ecumenical about platforms can we include > Shibboleth, i-name etc. along with OpenID in "user-centric identity"? > > If so I am interested. > > Wes Kussmaul > > > McGovern, James F (HTSC, IT) wrote: > Great to hear that you are working with salesforce.com. Would someone else > on this list volunteer to work with Siebel, Peoplesoft, SAP, Intalio and > Alfresco? > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 2:57 AM > To: McGovern, James F (HTSC, IT) > Cc: specs@openid.net > Subject: Re: Promoting OpenID > > > > On 2-Apr-07, at 8:15 AM, McGovern, James F ((HTSC, IT)) wrote: > > > > Is anyone here working with vendors in the ERP, CRM, ECM, BPM or > VRM spaces such that user-centric identity is built into their > product? > > We are working with salesforce.com ... > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Web Access Management
Is that really true Mart? Isn't it at least as much the perception that OpenID isn't usable by organizations acting as RP's that cannot manage the risk associated with accepting an authentication assertion from OP "out there"? That is, the perception is that OpenID is good for Jyte and blog comments, but not for anything serious or of value (on the RP side)? This perception is reasonable from some points of view. And there's the Phishing concerns... I do think the IPR stuff is an issue (of course), but I don't think it's the main reason there isn't more interest from the big (RP-oriented) players yet. I think there's been little said to assuage the above concerns because many of the folks here aren't interested, as a matter of world-view, in the problems of large RP's who have business risks associated with unknown OP's. Those risks *can* be addressed and/or mitigated in a number of interesting ways, but we're still pretty early on in the development of OpenID as a deployed infrastructure now... -Gabe > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Martin Atkins > Sent: Thursday, April 05, 2007 4:41 PM > To: specs@openid.net > Subject: Re: Web Access Management > > Hans Granqvist wrote: > >> Ping demoed OpenID technology at RSA. > >> > >> I hear Novell and IBM are looking at supporting OpenID. > >> > >> Microsoft has said they will in future products. > >> > >> Oracle and CA are following OpenID. > >> > >> So, yes. :-) > >> > > > > I'm curious why almost all of these companies are non-existent > > on the mailing lists. Any insights? > > > > It seems that at this time the uncertain policies for issues such as > patents and trademarks surrounding OpenID are putting off larger > companies from directly participating. > > This is a current hot-topic for the OpenID Foundation, since getting > such companies fully on board would likely be beneficial. > > > ___ > 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: Attribute Exchange 1.0 svn revision 295 review
On Apr 5, 2007 at 8:41 AM, Dick Hardt <[EMAIL PROTECTED]> wrote: > > There is no way to say "I want as many of X as you have, and I don't > > care how many that is" > > Good point. Perhaps have a magic value like -1 to indicate as many > as the user will release? > I had thought the RP would likely have a maximum they would want in > most situations. Generally, yes, although when we were discussing the spec, we talked about using one pass of attribute exchange to get all of the available attributes and another pass to request the attributes themselves. When requesting the available attributes, it seems like you'd want to say "give me all the attributes that are available" instead of "give me up to 500 available attributes," but I could be wrong. It might be good to give a bound on the response size for every request, although in cases such as above, it might be useful to the relying party to know if there were values that overflowed the limit. It wouldn't be difficult to add a flag, but I'm also not sure whether it would be worth the extra complexity. > > There is the issue that I brought up in a separate message where > > count=1 is different from not specifying a count, even though they > > both mean 1 or 0 values. > > The perl way would be to have "more then one way to do it" and allow > both methods to mean the same thing. > > The python way would be "there is one way to do it" and not allow > count=1 in a request Well, clearly it's better to have one way to do it. But seriously, the main problem that I have with it is that the specification prescribes the response format based on the request format. That is, my code has to keep track of whether the request used count=1 or just didn't specify a count, instead of just recording that the request asked for one value, so that the later code can know how to encode the value. If there's really more than one way to do it, you should be allowed to do it either way. I'm guessing that you made that restriction on the response format so that relying parties can know what the form of the response will be. Is that correct? Another restriction on the response message is that you have to send responses even if they are empty. Can you give the rationale for requiring the fields with no values to be sent? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
Hans Granqvist wrote: >> Ping demoed OpenID technology at RSA. >> >> I hear Novell and IBM are looking at supporting OpenID. >> >> Microsoft has said they will in future products. >> >> Oracle and CA are following OpenID. >> >> So, yes. :-) >> > > I'm curious why almost all of these companies are non-existent > on the mailing lists. Any insights? > It seems that at this time the uncertain policies for issues such as patents and trademarks surrounding OpenID are putting off larger companies from directly participating. This is a current hot-topic for the OpenID Foundation, since getting such companies fully on board would likely be beneficial. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Chris Drake wrote: > Hi Martin, > > Yes - sorry - I accidentally hit "reply" instead of "reply all". I > later did re-post to the list though. For the benefit of the list, > your reply is at the end here. > > Re-reading my reply, I think my wording sounded pretty strong, and I > might not have made it clear that I'm not pushing for 100% of data to > "live" at the OP: rather - I want to give the user a choice in the > matter (that is - after all - the entire spirit of "user-centric"). I > want users to have the *option* to decide whether to "sign up" to RP#A > or RP#B, and be able to base their decision upon the data-handling and > protection practices of the RP. Some RP's will want to store > everything just like they do today. Some will want to embrace user > centricity and give their customers full control, and most will > probably tread a line somewhere inbetween. > > As long as we build something that supports all this, then we can > leave it up to the normal market forces to steer the "Identity future" > the way they want - with the key issue (for us) being that OpenID has > the chance to persist in this future. Right now - OpenID is right at > the bottom of the pile, being almost the worst "Identity 2.0" protocol > currently on the market. IMHO - this is a problem that's easily > fixed. > I believe we are aiming for much the same thing, though perhaps I'm coming at it from a different perspective. My original message was proposing support for expressing the user's desires for how long particular data items should be retained without refreshing them, which seems to fit into your world view as described above. I was simply suggesting that expecting RPs to retain *no information at all* is unrealistic, and so we should provide a mechanism for users to express how they would like their data to be used rather than just assuming that RPs will retain nothing. > I wrote: >>> Yes - this could be a tough drain on RP and OP resources. Tough. > You wrote: > MA> You can't just wash your hands of this problem because it doesn't suit > MA> your rather bizarre idea about how the world should be. Sites need to be > > I contest that I *am* allowed to "wash my hands" at this point, > because it is absolutely my problem: I operate an OP, and I'm involved > in helping RPs accomplish "Web 2.0" goals. I'm smack in the middle of > all the consequences that flow from allowing users to control their > own data howsoever they wish. > > I further contest that the idea of me being in control of my own > information about me is not bizarre. It might not be how anything on > the web works today - true - but I'm pretty confident this is > something most people do, or will, want. > > Imagine you're at the newsagent buying a magazine. You hand over > your credit card, and the shopkeeper says "No problem - I'm happy to > sell you your goods, but I need you to first agree to let me make a > photocopy of your credit card, grab you name and email address, and > keep it in all on our files for the next 10 years. Oh - and we'll > need to be sending you the occasional marketing message from time to > time over those 10 years as well." > > Now *that* is something that almost everyone will agree is bizarre. > Note that I was focusing on the example you gave of a user's name, rather than of a user's credit card information. Different data deserves different treatment. I'll wholeheartedly agree that it's undesirable for a vendor to retain credit card information — they currently do so largely because there's nowhere else that it can be centrally stored and retrieved, but AX changes that — but other data such as a user's name are another matter. When I meet people, I routinely tell them my name. I don't expect them to immediately forget my name after our conversation — in fact, like most people, I'm probably subconsciously offended when people *don't* remember my name. I control people's access to that data by simply not telling them in the first place. I think that what we can take from this misunderstanding is that not only do different *attributes* have different usage expectations, but also different *situations* have different usage expectations: you're largely focusing on businesses and financial transactions, while I'm largely focusing on social situations such as forums, weblogs and social networking. This may be caused by a difference in our backgrounds or interests, but whatever the reason it does show that different situations call for different behavior, and is yet another reason why users should be able to express their desires on a case-by-case basis if it is important for them to do so. I like Vinay's subsequent suggestion that this somehow be made legally binding, although I'm not sufficiently knowledgable about the relevant law to know how that can be put into practice. [snip] ___ specs mailing list specs@openid.net http://openi
RE: Web Access Management
The RSA CTO is Bret Hartman, the Netegrity CTO is Vadim Lander. I would also suggest inviting Marc Wilcox from Oracle. I don't know the names of folks from Novell or IBM. Would be great if Dick reached out to them. -Original Message- From: Hans Granqvist [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 1:05 PM To: Dick Hardt Cc: McGovern, James F (HTSC, IT); specs@openid.net Subject: Re: Web Access Management > Ping demoed OpenID technology at RSA. > > I hear Novell and IBM are looking at supporting OpenID. > > Microsoft has said they will in future products. > > Oracle and CA are following OpenID. > > So, yes. :-) > I'm curious why almost all of these companies are non-existent on the mailing lists. Any insights? -Hans * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Web Access Management
> Ping demoed OpenID technology at RSA. > > I hear Novell and IBM are looking at supporting OpenID. > > Microsoft has said they will in future products. > > Oracle and CA are following OpenID. > > So, yes. :-) > I'm curious why almost all of these companies are non-existent on the mailing lists. Any insights? -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
some questions on OpenID AX 1.0 draft 4
http://openid.net/specs/openid-attribute-exchange-1_0-04.html 1. Section 2 states that the store operation "saves or updates attribute information on the OpenID Provider." How does an RP delete an attribute when updating information on the OP? 2. Section 3.2 states that "If an attribute type identifier URI can be resolved then it MAY be dereferenced to retrieve a description of the property." In this protocol, who is doing the dereferencing? Would an OP return an error during a store if it resolved the URI and there was no description of the property there? 3. Section 3.3 states that an attribute value MUST be a UTF-8 string. Are any UTF-8 characters permitted? How is a newline escaped, as Section 4.1.1 of http://openid.net/specs/openid-authentication-2_0-10.txt states that "A key or value MUST NOT contain a newline". Presumably RFC 2482 characters (plane 14 language tags) are OK? Or are language tags of values carried through some other means? How can the RP determine the maximum value length that an OP will support for a particular attribute? 4. Section 5.1 states that "Attribute aliases MUST NOT contain newline and colon characters,... they also MUST NOT contain commas." What is the significance of a period character? Can an alias "contain" a period? What is the maximum length of an alias string that an RP can expect an OP to support? 5. Section 5.1 states that if openid.ax.if_available parameter is present "The OpenID Provider MAY provide the identity information specified in this parameter.". How does the RP determine the schema of the provider to know what to ask for? 6. Section 5.1 states that "openid.ax.count." is "the number of values for the specified attribute alias the Relying Party wishes to receive from the OpenID Provider. If present, the value MUST be greater than zero. If absent, exactly one value is requested. OpenID Providers MUST NOT return more than the number of requested values." What is the largest value of count that an RP that wants "all values" can submit that an OP will support? 2^31? 2^32? 2^63? 7. Section 5.2 states that "The value of the openid.ax.type. parameter specifies the type identifier URI for the attribute referred to as . MUST be present if, and only if, this exact parameter was included in the fetch request." It's not clear to me how subtyping of attributes is handled. Suppose the OP holds a 'person' with attributes ldap:///cn=schema#cn: John Smith ldap:///cn=schema#cn: Johnny Smith ldap:///cn=schema#surname: Smith ldap:///cn=schema#givenName: John ldap:///cn=schema#patronymic: Paul Now the attribute types ldap:///cn=schema#cn, ldap:///#cn=schema#patronymic, ldap:///cn=schema#surname, ldap:///cn=schema#givenName are all subtypes of a generic attribute type ldap:///cn=schema#name. In LDAP directories, when one asks for a 'name' attribute, that's a shorthand for asking for any of the naming attributes, which can be useful if the requestor doesn't know in advance what schema attributes the server uses for naming people. A RP issues a fetch request for ldap:///cn=schema#name, asking for "any naming information" . The OP doesn't have a #name attribute in that person, but does have #cn, #surname, #patryonmic and #givenName attributes. How should the OP encode these types in the fetch response to the RP? 8. Section 6.1 states that "openid.ax.value. assigns a value to the attribute referred to as ." Is an OP receiving a store response required to save the alias provided by the RP for any purpose, or is the alias merely used in a particular protocol interaction? 9. Section 6.1 states that "openid.ax.value.. assigns a value to the attribute referred to as . The uniquely identifies the index of the value, ranging from one to the value specified by "openid.ax.count.". Is the OP required to preserve the order? 10. Is it legal for the values of a multi-valued attribute to be bytewise identical, e.g.: openid.ax.value.fav_movie.1=Movie1 openid.ax.value.fav_movie.2=Movie1 11. How can the RP determine the maximum value count that an OP will support? 12. Is it legal for the store request to be used to add values without restating existing values, e.g. openid.ax.type.fav_movie=http://example.com/schema/favourite_movie openid.ax.count.fav_movie=1 openid.ax.value.fav_movie.3=Movie3 If a store request includes fewer values than what are stored, then presumably the OP will delete the other values? 13. How is a race condition avoid if two RPs both want to 'add' a value to the same attribute. (e.g., RP blockbuster wants to add movieX to my "movie's I've seen" attribute, and RP netflix wants to add movieY to my "movie's I've seen" attribute). Maybe there could be a magic number of "greater than any other"? 14. Similarly, there doesn't seem to be support for counter-valued attributes in the OpenID attribute exchange.In order for an RP to increment a value stored in the OP, the RP would need to fetch
Re: Attestation
That wasn't quite my point. My point was that if some assertion changes once a minute, but might only be requested by anybody once a month, one would construct a solution fundamentally differently than if the assertion changed once a decade, and it might be requested once a day.On Apr 5, 2007, at 9:16, Brian Hernacki wrote: It would seem preferable for the verifier to simply specify an arbitrary period of validity at the time of signing as there are likely to be more than just two cases. --brian On 4/5/07 9:13 AM, "Johannes Ernst" <[EMAIL PROTECTED]> wrote: There seem to be at least two variations of attestation if we differentiate by how quickly the underlying statement (claim, ...) may change. E.g. 1. long-term: X is a citizen of country Y. If it changes at all, it takes years. 2. short-term: X is in the same room with me. It changes minute by minute. In the first case, we can do things like sign a claim and show that signed claim every time somebody asks. In the second, we might have to ask the asserting party in real time? ___specs mailing listspecs@openid.nethttp://openid.net/mailman/listinfo/specs Johannes ErnstNetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Dick, see my other message but this is not about ME stopping you! >> We wanted to publish them on the website so that other people could >> look at them, but you did not want to do that, and you control the >> domain. > > Dick, that isn't a fair statement at all. It is not my decision to > make if schemas.openid.net should be created and the content you're > proposing put there. I've asked you multiple times to have a > conversation on this list ending in a formal vote (like we've done > for many other spec decisions) to make this decision. If I've missed > this vote then please point me at it. I'm quite honestly not sure what more to say. If you want to see this work happen then you need to take the initiative and make it happen. You can't just expect to post a few messages to the ID Schemas list and have them magically start working. I'm all about taking advantage of existing momentum, but I have a hard time seeing anyone who cares about AX being unwilling to have this discussion as a part of the ID Schemas community. If there is anyone, I'd certainly like to understand the reasons why (beyond it being "hard"). --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 9:18 AM To: Recordon, David Cc: Drummond Reed; Johnny Bufu; OpenID specs list; [EMAIL PROTECTED] Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) If you would let us put the attributes on the website, then other people could see them and comment on them. On 5-Apr-07, at 9:02 AM, Recordon, David wrote: > I guess I don't see why blaming the ID Schemas project for not much > happening is a good excuse for not doing it there. Blame? ... just stating a fact. > People who care will > either have to drive this work within the OpenID project or the ID > Schemas project; I fail to see how the effort required in each differs > greatly. In some senses, I think if people gather as part of the ID > Schemas project and try to move this work forward, it will actually be > more successful than trying to do it here. People have not gathered and done work on the ID Schemas project to date. People are now gathering on the OpenID list around AX -- so let's use that momentum. I stated several reasons why it makes sense to do it here. > Nothing done by OpenID in the past has intrinsically been easy which > is why I continue to think that something being hard is not a valid > reason to not do the right technical/social thing. I know that these > two communities can work together, but the onus is on the OpenID AX > side to make this conversation successful and drive progress. Oh, so if we add MORE people to the mix it will be easier!!! :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Attestation
I believe that specifying an arbitrary time is the better way to go as it puts the work into the hands of the user. Otherwise, you would go down a rathole in that a provider otherwise may then require the ability to express a policy against it. Message: 6 Date: Thu, 05 Apr 2007 09:16:20 -0700 From: Brian Hernacki <[EMAIL PROTECTED]> Subject: Re: Attestation To: OpenID specs list Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" It would seem preferable for the verifier to simply specify an arbitrary period of validity at the time of signing as there are likely to be more than just two cases. --brian On 4/5/07 9:13 AM, "Johannes Ernst" <[EMAIL PROTECTED]> wrote: > There seem to be at least two variations of attestation if we differentiate by > how quickly the underlying statement (claim, ...) may change. E.g. > > 1. long-term: X is a citizen of country Y. If it changes at all, it takes > years. > 2. short-term: X is in the same room with me. It changes minute by minute. > > In the first case, we can do things like sign a claim and show that signed > claim every time somebody asks. In the second, we might have to ask the > asserting party in real time? > * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attestation
It would seem preferable for the verifier to simply specify an arbitrary period of validity at the time of signing as there are likely to be more than just two cases. --brian On 4/5/07 9:13 AM, "Johannes Ernst" <[EMAIL PROTECTED]> wrote: > There seem to be at least two variations of attestation if we differentiate by > how quickly the underlying statement (claim, ...) may change. E.g. > > 1. long-term: X is a citizen of country Y. If it changes at all, it takes > years. > 2. short-term: X is in the same room with me. It changes minute by minute. > > In the first case, we can do things like sign a claim and show that signed > claim every time somebody asks. In the second, we might have to ask the > asserting party in real time? > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
If you would let us put the attributes on the website, then other people could see them and comment on them. On 5-Apr-07, at 9:02 AM, Recordon, David wrote: > I guess I don't see why blaming the ID Schemas project for not much > happening is a good excuse for not doing it there. Blame? ... just stating a fact. > People who care will > either have to drive this work within the OpenID project or the ID > Schemas project; I fail to see how the effort required in each differs > greatly. In some senses, I think if people gather as part of the ID > Schemas project and try to move this work forward, it will actually be > more successful than trying to do it here. People have not gathered and done work on the ID Schemas project to date. People are now gathering on the OpenID list around AX -- so let's use that momentum. I stated several reasons why it makes sense to do it here. > Nothing done by OpenID in the past has intrinsically been easy > which is > why I continue to think that something being hard is not a valid > reason > to not do the right technical/social thing. I know that these two > communities can work together, but the onus is on the OpenID AX > side to > make this conversation successful and drive progress. Oh, so if we add MORE people to the mix it will be easier!!! :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
> I don't think this is really that important of a point given all the > other things we need to do. People are doing to do things different > then you would, but get the same result -- is that ok? I'm fine with doing things differently, I'm not arguing that a metadata format should not be created, just that IMHO for simplicity sake of reading the AX documents this format description should be merged into the core protocol spec. If down the road it should be split out then it always can be. > We wanted to publish them on the website so that other people could > look at them, but you did not want to do that, and you control the domain. Dick, that isn't a fair statement at all. It is not my decision to make if schemas.openid.net should be created and the content you're proposing put there. I've asked you multiple times to have a conversation on this list ending in a formal vote (like we've done for many other spec decisions) to make this decision. If I've missed this vote then please point me at it. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 9:13 AM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 5-Apr-07, at 9:06 AM, Recordon, David wrote: >> Actually it is describing a document format, and it could easily be > used >> by other groups as evidenced by references from people in the ID > Schemas >> group. > I agree that it could be, but is anyone? It leaves the option open. > I love shooting beyond the 80% > to get the remaining 20%, but if that is just a pipe dream then I have > a hard time seeing why the documents need to be separate and thus more > complex. An RP does not need to worry about the metadata, so it is much easier for an RP to implement if they don't need to look at the other document. I don't think this is really that important of a point given all the other things we need to do. People are doing to do things different then you would, but get the same result -- is that ok? > >> We defined a set of attributes 6 months ago under schema.openid.net. > So Dick, this is part of my problem with AX. Sxip has defined a set > of attributes and never gained consensus on this list that that is the > right thing to do. We wanted to publish them on the website so that other people could look at them, but you did not want to do that, and you control the domain. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
On Apr 5, 2007, at 9:02, Recordon, David wrote: In some senses, I think if people gather as part of the ID Schemas project and try to move this work forward, it will actually be more successful than trying to do it here. I would agree with this. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attestation
There seem to be at least two variations of attestation if we differentiate by how quickly the underlying statement (claim, ...) may change. E.g. 1. long-term: X is a citizen of country Y. If it changes at all, it takes years. 2. short-term: X is in the same room with me. It changes minute by minute. In the first case, we can do things like sign a claim and show that signed claim every time somebody asks. In the second, we might have to ask the asserting party in real time? On Apr 5, 2007, at 7:33, McGovern, James F ((HTSC, IT)) wrote: The term attestation has a distinct legal meaning but within an IT context may be used interchangably with the notion of certification or periodic review. There are of course several levels of attestation. I propose that minimally OpenID incorporate the first notion where someone certifies you are who you say you are. In an enterprise environment, a manager may attest that a particular employee is still employed by them. In a user-centric world, if we could have the ability to digitally "sign" either a managed-card (in an enterprise setting) or across providers in a user setting along with capturing transactional attributes such as when it was signed, how long is this signature good for, the ability to revoke, etc we should be covered. Finally, an attestor should be able to choose from an enumeration of relationships such as spouse, manager/employer, service provider/ customer, etc. What would it take to change the OpenID XML to incorporate? ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
On 5-Apr-07, at 9:06 AM, Recordon, David wrote: >> Actually it is describing a document format, and it could easily be > used >> by other groups as evidenced by references from people in the ID > Schemas >> group. > I agree that it could be, but is anyone? It leaves the option open. > I love shooting beyond the 80% > to get the remaining 20%, but if that is just a pipe dream then I > have a > hard time seeing why the documents need to be separate and thus more > complex. An RP does not need to worry about the metadata, so it is much easier for an RP to implement if they don't need to look at the other document. I don't think this is really that important of a point given all the other things we need to do. People are doing to do things different then you would, but get the same result -- is that ok? > >> We defined a set of attributes 6 months ago under schema.openid.net. > So Dick, this is part of my problem with AX. Sxip has defined a > set of > attributes and never gained consensus on this list that that is the > right thing to do. We wanted to publish them on the website so that other people could look at them, but you did not want to do that, and you control the domain. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
> Actually it is describing a document format, and it could easily be used > by other groups as evidenced by references from people in the ID Schemas > group. I agree that it could be, but is anyone? I love shooting beyond the 80% to get the remaining 20%, but if that is just a pipe dream then I have a hard time seeing why the documents need to be separate and thus more complex. If however this format was defined within the ID Schemas project, then that would be an easy argument as to why they should be separate. > We defined a set of attributes 6 months ago under schema.openid.net. So Dick, this is part of my problem with AX. Sxip has defined a set of attributes and never gained consensus on this list that that is the right thing to do. See my other message a few minutes ago as to the rest of my thoughts. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 8:27 AM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 4-Apr-07, at 1:16 PM, Recordon, David wrote: > Johnny, > I see a lot of, at least my initial confusion, coming from there being > multiple documents. This is why I urge merging the transport and > metadata since the reality is they currently are only being used with > each other. As the metadata document doesn't actually define a new > format, rather references existing formats, I am unsure why it cannot > just be a section in the transport document. It is understood that > you must use the metadata format for the schema URLs in the transport, > so the two documents really are coupled to begin with. Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. > > I agree that you need to bootstrap a set of attributes for people > using AX. As I have done so in the past, I'd encourage this work > happen within the ID Schemas project (http://idschemas.idcommons.net/) > versus defining First Name yet again for openid.net. I have no > problem with the spec listing a set of schema URLs, I just strongly > feel that anything non-OpenID specific should be hosted and defined > elsewhere since so many people have already done it. I do understand > the need for the schema URL hosting the metadata document, which is > why I am advocating this work be done as part of the ID Schemas > project to provide this flexibility. see my response to Drummond ... We defined a set of attributes 6 months ago under schema.openid.net. I think we have let other groups have time to do something, I'd like to get on with building and deploying stuff. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
I guess I don't see why blaming the ID Schemas project for not much happening is a good excuse for not doing it there. People who care will either have to drive this work within the OpenID project or the ID Schemas project; I fail to see how the effort required in each differs greatly. In some senses, I think if people gather as part of the ID Schemas project and try to move this work forward, it will actually be more successful than trying to do it here. Nothing done by OpenID in the past has intrinsically been easy which is why I continue to think that something being hard is not a valid reason to not do the right technical/social thing. I know that these two communities can work together, but the onus is on the OpenID AX side to make this conversation successful and drive progress. Cc'ing their list as well. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 8:00 AM To: Drummond Reed Cc: Recordon, David; 'Johnny Bufu'; 'OpenID specs list' Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) Doing the work in the ID Schemas project was a good idea 3 months ago and 6 months ago. So far not much has happened there. I agree that having several groups do the same thing is undesirable, but we do need to get moving. We need URIs for moving attributes today. We can wait for the metadata [1] to get defined, and the members of the ID Schema group are the right people for that.[2] While it is desirable that there is only one definition of an attribute, and some people may define the same attribute through lack of knowledge of each other. The attribute meta data model proposed[1] allows for one definition to reference another definition to consolidate attribute definitions. Additionally, getting everyone to agree on the syntax will be hard. The model allows different people to define attributes in different ways. The market will decide then what works best through use. btw: Currently there is no consistent, extensible, self describing attribute schema system out there that I know of, or anyone in the ID Schema Working group knows of. We can start to define attributes in the openid.net namespace and then reference more "authorative" URIs when they exist. This would let the OpenID community define the immediately required attributes for people to implement and deploy AX, which will likely increase awareness [1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html [2] Of course we have all the issues of IPR etc. at the ID Schema working group since it would be unclear what organization would be managing that spec. Over here in the OpenID community we are working to resolve that, so perhaps the ID Schema people could participate in a list hosted at openid.net? -- Dick On 4-Apr-07, at 10:27 PM, Drummond Reed wrote: > +1 to defining attribute identifier URIs/XRIs in the Identity > Commons ID > Schemas project. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Recordon, David > Sent: Wednesday, April 04, 2007 1:16 PM > To: Johnny Bufu > Cc: OpenID specs list > Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback) > > Johnny, > I see a lot of, at least my initial confusion, coming from there being > multiple documents. This is why I urge merging the transport and > metadata since the reality is they currently are only being used with > each other. As the metadata document doesn't actually define a new > format, rather references existing formats, I am unsure why it cannot > just be a section in the transport document. It is understood that > you > must use the metadata format for the schema URLs in the transport, so > the two documents really are coupled to begin with. > > I agree that you need to bootstrap a set of attributes for people > using > AX. As I have done so in the past, I'd encourage this work happen > within the ID Schemas project (http://idschemas.idcommons.net/) versus > defining First Name yet again for openid.net. I have no problem with > the spec listing a set of schema URLs, I just strongly feel that > anything non-OpenID specific should be hosted and defined elsewhere > since so many people have already done it. I do understand the > need for > the schema URL hosting the metadata document, which is why I am > advocating this work be done as part of the ID Schemas project to > provide this flexibility. > > --David > > -Original Message- > From: Johnny Bufu [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 12:39 PM > To: Recordon, David > Cc: Dick Hardt; OpenID specs list > Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) > > > On 4-Apr-07, at 12:18 PM, Recordon, David wrote: >> One thing that I do think would be worthwhile in smoothing more of >> this SREG/AX confusion would be adding SREG support to Sxip's OpenID >> libraries. > > This is on the todo list, and judgi
Re: Attribute Exchange 1.0 svn revision 295 review
On 4-Apr-07, at 2:07 PM, Josh Hoyt wrote: > Is editing of this spec by authors of other OpenID specifications > welcome? (I hope that by this review and my past spec work I'm showing > that I have adequate understanding and appropriate goals.) Yes! Great feedback below > Update URL issues > = > > I assume that the update_url is intended to match the realm of the > authentication request. The spec doesn't say this anywhere. Good addition. > > There is no information about what form an update request will take, > or what a response to an update request will look like. Is an update > request supposed to be an OpenID authentication mode=id_res message? > If so, I think this is at least a little confusing, since the > user-agent of this HTTP transaction is not the user's browser, but the > provider's. The intention was that it was in the same format as the original message. Do you have another suggestion? > > There doesn't seem to be a way to expire an update URL or unsubscribe > from updates. Another good point. Returning a 404 would be one way to expire the URL. > > There is no discussion of how an OpenID provider should behave if an > update URL does not respond (retry? stop using that URL? some of > each?) That would seem to be implementation dependent as the OP is acting on behalf of the user, but agreed the spec should at least have a recommendation. > > Store Requests > == > > The realm in a store request is somewhat meaningless; The provider has > no way of knowing whether the data came from something that's in that > realm, even if a return_to URL is provided. The realm would be a hint > > What will happen to the data when a store is requested is not > discussed (will it replace the current value? will it get > concatenated? Does it depend on the attribute? If it's left up to the > provider, how will an RP know when it should initiate a store?) It is up to the OP to manage the attributes and deal with multiple values since this is the user's data. Not all that different from what an RP does when it gets data. An RP would initiate a store if it thinks the data will be useful to other RPs. > > Multiple Values > === > > There is no way to say "I want as many of X as you have, and I don't > care how many that is" Good point. Perhaps have a magic value like -1 to indicate as many as the user will release? I had thought the RP would likely have a maximum they would want in most situations. > > There is the issue that I brought up in a separate message where > count=1 is different from not specifying a count, even though they > both mean 1 or 0 values. The perl way would be to have "more then one way to do it" and allow both methods to mean the same thing. The python way would be "there is one way to do it" and not allow count=1 in a request > > The spec wording is unclear on what the count response parameter > should be. The example shows sending back a different count, which > suggests that the response count can be less than the request count, > but that should be explicit. good point > > Could we do away with unspecified count in the interests of simpler > code everywhere? That way, we always know there's a count and the data > is always accessed in the same way. Are you suggesting we always send the count? Most requests we have done only are requesting a single value, so that seems like lots of overhead. Agree having one way to do it has its advantages, you are showing your Python roots. :-) > > It's not clear from the specification whether zero-length strings as > values for things with a count should be treated the same as they are > for things without a count. Agree is is not clear. I would suggest zero-length is the value that is returned. If no value is to be returned, then nothing is sent. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
On 4-Apr-07, at 1:16 PM, Recordon, David wrote: > Johnny, > I see a lot of, at least my initial confusion, coming from there being > multiple documents. This is why I urge merging the transport and > metadata since the reality is they currently are only being used with > each other. As the metadata document doesn't actually define a new > format, rather references existing formats, I am unsure why it cannot > just be a section in the transport document. It is understood that > you > must use the metadata format for the schema URLs in the transport, so > the two documents really are coupled to begin with. Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. > > I agree that you need to bootstrap a set of attributes for people > using > AX. As I have done so in the past, I'd encourage this work happen > within the ID Schemas project (http://idschemas.idcommons.net/) versus > defining First Name yet again for openid.net. I have no problem with > the spec listing a set of schema URLs, I just strongly feel that > anything non-OpenID specific should be hosted and defined elsewhere > since so many people have already done it. I do understand the > need for > the schema URL hosting the metadata document, which is why I am > advocating this work be done as part of the ID Schemas project to > provide this flexibility. see my response to Drummond ... We defined a set of attributes 6 months ago under schema.openid.net. I think we have let other groups have time to do something, I'd like to get on with building and deploying stuff. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Server-to-server channel
I would think this would be better solved by leveraging the Oracle
Identity Framework and using components such as AAPML and CARML
Message: 3
Date: Thu, 5 Apr 2007 10:57:22 +
From: Vinay Gupta <[EMAIL PROTECTED]>
Subject: Re: Re[3]: Server-to-server channel
To: Chris Drake <[EMAIL PROTECTED]>
Cc: Martin Atkins <[EMAIL PROTECTED]>, specs@openid.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On having your private data cached: the current web model allows
businesses to simply own your data into a database, correlate it across
multiple databases (doubleclick) and so on.
I think that to expect them to give up this privilege (and revenue
stream from targeted advertising) is unrealistic, and caching OpenID
data is necessary for them to do so.
Therefore, I'd suggest that OpenID examines the various schemes for
providing a "Terms of Service" **from the user end** on access to
personal data: "by accessing my address, you attest that you will not
1> store it for more than 30 days after our business transaction is
complete, 2> share it with anybody else" and so on. I seem to remember
that somebody had a language for expressing those kinds of privacy
preferences in a machine readable form but I'm not having any luck
remembering who it was...
Possibly the XRI folks know?
At least at that point, users can use the penalty clause on that
"shrinkwrap license" on their personal data to sue scumbags ("and if you
break these rules, you pay me $500.") HIPPA may also help.
Vinay
*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Doing the work in the ID Schemas project was a good idea 3 months ago and 6 months ago. So far not much has happened there. I agree that having several groups do the same thing is undesirable, but we do need to get moving. We need URIs for moving attributes today. We can wait for the metadata [1] to get defined, and the members of the ID Schema group are the right people for that.[2] While it is desirable that there is only one definition of an attribute, and some people may define the same attribute through lack of knowledge of each other. The attribute meta data model proposed[1] allows for one definition to reference another definition to consolidate attribute definitions. Additionally, getting everyone to agree on the syntax will be hard. The model allows different people to define attributes in different ways. The market will decide then what works best through use. btw: Currently there is no consistent, extensible, self describing attribute schema system out there that I know of, or anyone in the ID Schema Working group knows of. We can start to define attributes in the openid.net namespace and then reference more "authorative" URIs when they exist. This would let the OpenID community define the immediately required attributes for people to implement and deploy AX, which will likely increase awareness [1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html [2] Of course we have all the issues of IPR etc. at the ID Schema working group since it would be unclear what organization would be managing that spec. Over here in the OpenID community we are working to resolve that, so perhaps the ID Schema people could participate in a list hosted at openid.net? -- Dick On 4-Apr-07, at 10:27 PM, Drummond Reed wrote: > +1 to defining attribute identifier URIs/XRIs in the Identity > Commons ID > Schemas project. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Recordon, David > Sent: Wednesday, April 04, 2007 1:16 PM > To: Johnny Bufu > Cc: OpenID specs list > Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback) > > Johnny, > I see a lot of, at least my initial confusion, coming from there being > multiple documents. This is why I urge merging the transport and > metadata since the reality is they currently are only being used with > each other. As the metadata document doesn't actually define a new > format, rather references existing formats, I am unsure why it cannot > just be a section in the transport document. It is understood that > you > must use the metadata format for the schema URLs in the transport, so > the two documents really are coupled to begin with. > > I agree that you need to bootstrap a set of attributes for people > using > AX. As I have done so in the past, I'd encourage this work happen > within the ID Schemas project (http://idschemas.idcommons.net/) versus > defining First Name yet again for openid.net. I have no problem with > the spec listing a set of schema URLs, I just strongly feel that > anything non-OpenID specific should be hosted and defined elsewhere > since so many people have already done it. I do understand the > need for > the schema URL hosting the metadata document, which is why I am > advocating this work be done as part of the ID Schemas project to > provide this flexibility. > > --David > > -Original Message- > From: Johnny Bufu [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 12:39 PM > To: Recordon, David > Cc: Dick Hardt; OpenID specs list > Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) > > > On 4-Apr-07, at 12:18 PM, Recordon, David wrote: >> One thing that I do think would be worthwhile in smoothing more of >> this SREG/AX confusion would be adding SREG support to Sxip's OpenID >> libraries. > > This is on the todo list, and judging by the interest showed by some > contributors could happen any day now. > >> Any thoughts on spec consolidation > >> I think I'd propose the following: >> - Remove http://openid.net/specs/openid-attribute- >> types-1_0-02.html (I >> do not believe OpenID should define its own schema elements for >> things > >> like "First Name" which are not specific to OpenID, defining a URL >> for > >> an OpenID enabled URL for example I think would be fine on >> OpenID.net) > > I understand that point of view and we were looking into determining > what would be the best place where this spec could live. > > However, since the AX's adoption will depend (at least in the > beginning, > before the metadata and automatic acquisition mechanisms are > finalized) > on the participants using the same "names" for the attributes they > transfer. From this point of view, I believe AX could use openid.net's > recommendation (if endorsement is too much) to use a set of names / > URIs > for the most commonly transfered attributes. > (Kind of like what ma
Attestation
The term attestation has a distinct legal meaning but within an IT context may be used interchangably with the notion of certification or periodic review. There are of course several levels of attestation. I propose that minimally OpenID incorporate the first notion where someone certifies you are who you say you are. In an enterprise environment, a manager may attest that a particular employee is still employed by them. In a user-centric world, if we could have the ability to digitally "sign" either a managed-card (in an enterprise setting) or across providers in a user setting along with capturing transactional attributes such as when it was signed, how long is this signature good for, the ability to revoke, etc we should be covered. Finally, an attestor should be able to choose from an enumeration of relationships such as spouse, manager/employer, service provider/customer, etc. What would it take to change the OpenID XML to incorporate? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: Server-to-server channel
On 4-Apr-07, at 8:59 PM, Chris Drake wrote: > Thursday, April 5, 2007, 5:43:02 AM, you wrote: > > [snip] > > DO> How these keys are handled internally could be left to the > DO> consumer or RP. > > [snip] > > This sounds like another *strong* use-case for updating the OpenID > protocol to allow transactions to take place when the user is not > present. > > I am not likely to be present when people relying upon my certificates > choose to verify signatures, check for revocation, or attempt to > encrypt stuff destined for me. > > There needs to be a way for the RP to contact my OP and get access to > my information (eg: my current public key and revocation list) - by my > explicit prior consent of course. Having your public key discoverable at your URL makes lots of sense, it is by its very nature, public. I would not consider fetching the public key to be a transaction though. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Features for Future Versions
Les, your scenario sounds similar to what we would like to see accomplished. Your phrase "I could have each application just write code via some API" feels like this is an opportunity for using the Oasis XACML specification. Most folks here are familiar with SAML which by the way supports an XACML profile. It seems as if folks are stuck solely on attribute exchange with is probably suitable for consumerish stuff but XACML would be better suited for B2B scenarios. -Original Message- From: Chasen, Les [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 2:49 PM To: Drummond Reed; Dick Hardt; McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: RE: Features for Future Versions I also agree with the feedback however I wanted to just pass along how I am using authentication and authorization on a series of applications that I am working on. I have a couple of applications that use standard openid authentication using XRDS documents but they also require the user to be authorized to use particular resources. In most cases authorization can be accomplished by profile data in a local database. In my case, though, the authorization comes from data in a third party database. I could have each application just write code via some API to the third party data source but I also want to provide for this capability to be federated to multiple trusted sources. I am therefore taking advantage of the service end point selection capability described in the XRI resolution spec at http://www.oasis-open.org/committees/download.php/17293. contact: =les sip: =les/(+phone) chat: =les/skype/chat * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[3]: Server-to-server channel
On having your private data cached: the current web model allows
businesses to simply own your data into a database, correlate it
across multiple databases (doubleclick) and so on.
I think that to expect them to give up this privilege (and revenue
stream from targeted advertising) is unrealistic, and caching OpenID
data is necessary for them to do so.
Therefore, I'd suggest that OpenID examines the various schemes for
providing a "Terms of Service" **from the user end** on access to
personal data: "by accessing my address, you attest that you will not
1> store it for more than 30 days after our business transaction is
complete, 2> share it with anybody else" and so on. I seem to
remember that somebody had a language for expressing those kinds of
privacy preferences in a machine readable form but I'm not having any
luck remembering who it was...
Possibly the XRI folks know?
At least at that point, users can use the penalty clause on that
"shrinkwrap license" on their personal data to sue scumbags ("and if
you break these rules, you pay me $500.") HIPPA may also help.
Vinay
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Wed, 2007-04-04 at 20:02 +, Vinay Gupta wrote: > On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote: > > Hm. Well, I don't to suggest that we tear off fixing or expressing > the whole semantics of PKI, but I do think that some care should be > taken to make sure that it's clear what the security status of a > returned key is. Problems like Confused Deputy can easily arise when > you start dealing with registry systems which aren't under really > tight control. > > I don't have a neatly packaged solution for this, but we're dealing > with situations which can have very significant legal repercussions: > digital signatures are legal for some kinds of transactions in some > jurisdictions, and however this is handled is has to have some > approach to the questions of "what is they key good for, and who says OpenID appears fairly prone to phishing exploits, as it expects a user to pay close attention to where they end up and the other URL involved. OpenID could evolve into offering public keys during the initial logins along with other identity attributes that could help solve this problem. The RP could retain keys for some period since last use to suppress the number of times OpenID is invoked. Rather than an expiry, the attribute might want to be defined differently. Some key agent would be needed that replicates the authentication process now available using SSH. This does not depend upon certificates, but rather a simple list of public keys. Once this concept becomes routine, other applications will likely include this mode of operation where identifying the application becomes important. This would _not_ be a certificate as you seem to imply. Try to keep it simple, but if an attribute can include a Time to Live or Expiry parameter, then it would be nice to have a class of attributes identified as public keys with sub-attributes for the application, where the default would be some OpenID compliant HTTP access scheme. An application that would not require development, other than maintaining a list of keys, would be SSH. Although perhaps too complex for the average user, SSH could also be used to authenticate web access. This is standard for any Unix based OS, and could be found by using Putty and Pageant on a Windows platform. There is even an interesting version of this that runs from a USB flash: http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ Although the world demands GUI, terminal interfaces already offer a powerful set of tools for doing exactly what is needed. Public key cryptography reduces the overhead and security concerns substantially. This may also provide an alternative for rather complex OpenID extensions that will likely over reach with respect to security. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel (now: Kerberos, Phishing)
One further thought on Kerberos: as far as I know, Kerberos is a minimal implementation - nothing simpler than this actually works in the real world, and the Kerberos operating environment is a bit simpler than what is being discussed in some instances here, in terms of managing the language of what access permissions are being granted by this sign-on event. One thing I'd like to suggest we examine is personal customization as a way to prevent Phishing. For example, say that my OpenID service provider serves pages to me over HTTPS, and furthermore allows me to upload my own color preference and background images. Now, nobody who isn't logged in as me can see my image and colors, so if somebody tries to mount Man In The Middle, they can't get access to my images etc. and the page will look all wrong. Sounds dumb but it might actually work pretty well in practice... But the key is that those images have to be private, so that they foe can't spider the page and show you a copy. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote: > Although the world demands GUI, terminal interfaces already offer a > powerful set of tools for doing exactly what is needed. Public key > cryptography reduces the overhead and security concerns substantially. > This may also provide an alternative for rather complex OpenID > extensions that will likely over reach with respect to security. The literature on both Capability Based Operating Systems and Kerberos should be considered pretty closely here. It's very easy to design systems which are subject to man in the middle attacks and replay attacks, and the semantics of security are equally important (like "what did the user just cryptographically authorize? they thought they authorized access to their name, but the request lied about what it was for...") Kerberos has an exquisite design for handling network authentication and should probably be considered as a template for subsequent systems. It is old and well examined, and still trusted. Perhaps it would make sense to implement Kerberos over OpenID to solve some or all of these security problems? http://web.mit.edu/Kerberos/ Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[3]: Server-to-server channel
Hi Martin, Yes - sorry - I accidentally hit "reply" instead of "reply all". I later did re-post to the list though. For the benefit of the list, your reply is at the end here. Re-reading my reply, I think my wording sounded pretty strong, and I might not have made it clear that I'm not pushing for 100% of data to "live" at the OP: rather - I want to give the user a choice in the matter (that is - after all - the entire spirit of "user-centric"). I want users to have the *option* to decide whether to "sign up" to RP#A or RP#B, and be able to base their decision upon the data-handling and protection practices of the RP. Some RP's will want to store everything just like they do today. Some will want to embrace user centricity and give their customers full control, and most will probably tread a line somewhere inbetween. As long as we build something that supports all this, then we can leave it up to the normal market forces to steer the "Identity future" the way they want - with the key issue (for us) being that OpenID has the chance to persist in this future. Right now - OpenID is right at the bottom of the pile, being almost the worst "Identity 2.0" protocol currently on the market. IMHO - this is a problem that's easily fixed. I wrote: >> Yes - this could be a tough drain on RP and OP resources. Tough. You wrote: MA> You can't just wash your hands of this problem because it doesn't suit MA> your rather bizarre idea about how the world should be. Sites need to be I contest that I *am* allowed to "wash my hands" at this point, because it is absolutely my problem: I operate an OP, and I'm involved in helping RPs accomplish "Web 2.0" goals. I'm smack in the middle of all the consequences that flow from allowing users to control their own data howsoever they wish. I further contest that the idea of me being in control of my own information about me is not bizarre. It might not be how anything on the web works today - true - but I'm pretty confident this is something most people do, or will, want. Imagine you're at the newsagent buying a magazine. You hand over your credit card, and the shopkeeper says "No problem - I'm happy to sell you your goods, but I need you to first agree to let me make a photocopy of your credit card, grab you name and email address, and keep it in all on our files for the next 10 years. Oh - and we'll need to be sending you the occasional marketing message from time to time over those 10 years as well." Now *that* is something that almost everyone will agree is bizarre. Imagine, instead, the exact same thing occurs on a web site, instead of at a newsagent. Nobody even blinks when this gross misuse of *my* information actually does occur. I would go as far as to say that opinions contrary to mine about "how the world (internet) should be" are in fact the "bizarre" ones!! --- My suggestion for how an OP might choose to present the kinds of data-protection defaults users might want would be for the OP to have a set of "per-user global account preferences". Mum and Dad users can click the "convenient" radiobutton. Political activists can click the "strong protection" radiobutton. Folks inbetween can be given middle-road defaults, and/or anyone can be given per-use overrides. Whichever OPs (or OP software packages that you choose to download and run yourself) that do these things the best, should then quite quickly become the market leaders. As long as the protocol supports the protection, the market can innovatively offer it. The challenges I see at present, are these: 1. How should an RP advertise to an OP what it's server-to-server endpoint is. 2. How should an OP advertise to an RP the same thing. 3. How should an RP indicate to user-agents (eg: browser plugins like SSO enablers, secure chrome/anti-phishing/anti-virus addons, form-fillers, OP helpers [or even OP software itself, if running on an end-users home machine]) that it is an "OpenID 2.0" enabled service in the first place. I've pushed for this to be standardized and enforced, because it offers the absolute strongest future support for new technologies - and I do so again now. If my web browser, upon visiting www.example.com, can immediately detect that it's an OpenID 2.0 site (eg: through a tag on every page, or the root or base URL, or HTTP headers, or whatever) - a massive pile of cool opportunities all spring up to make "Web 2.0" *seriously* more compelling, useful, and protective for everyone. Heck - Cardspace already did this - so we don't even have to argue the merits: They learned the long, hard, and painful way that excluding the user agent seriously undermines the trust and usefulness of Identity management. Kind Regards, Chris Drake Thursday, April 5, 2007, 5:14:58 PM, you wrote: MA> Not sure if you deliberately took this off-list, but I'll reply directly MA> and let you divert it back to list if you want. :) MA> Chris Drake
Re: Server-to-server channel
[I initially sent this to Chris directly, because he sent his message to me directly. Then I noticed he'd also replied on the list. Hopefully he'll see this before my private reply and we can avoid another go-around of duplicate messages!] Chris Drake wrote: > > MA> For some things it's legitimate: they need to store your name because > MA> otherwise they'd need to talk to your OP (via you!) every time they > MA> render a page containing something attributed to you. > > OK - yes - I concede that some "data age" complexity does probably > creep back in if RPs choose to deny users the opportunity to audit the > use of user information. (If I've got a choice between 2 RPs, and RP1 > renders pages with my name in it, without giving me control over that, > while RP2 makes repeated calls to my OP every time it occurs: I'll > always choose to use RP2 - because it's the only one of the 2 options > that's "user centric", and gives me the ability to control the use of > my information. > > Yes - this could be a tough drain on RP and OP resources. Tough. > You can't just wash your hands of this problem because it doesn't suit your rather bizarre idea about how the world should be. Sites need to be able to attribute contributions to users, and in order to do that they need the user's name. A forum site cannot retrieve the name of every user that took part in a topic from their respective OPs while rendering the topic page. "Tough" is not an acceptable answer: rendering a topic page is a legitimate function of a forum site and attributing each message is necessary. > MA> they need to store your name because > MA> otherwise they'd need to talk to your OP (via you!) > "via you!" is not a correct statement. This is a "server-to-server" > topic: we're discussing a data flow that is "by your explicit prior > permission", but that takes place when you are not necessarily > present. Right. Some people had been talking about not allowing this out-of-band information fetching. Even without the need for the user to be present, it's still prohibitively expensive. > MA> For other things it's more dubious than that, but the fact that it > MA> is technically possible means that at least some RP's will do it. > MA> I think it'd be a mistake to write the spec under the assumption > MA> that they won't unless we're going to include something that > MA> prevents it. > I do not follow your logic. It looks like you're saying "there is an > opportunity for some RP's to act badly, therefore we should not even > try to code user-protection into the protocol" On the contrary, I'm saying that if you don't want RPs to retain user information then you should include some TECHNICAL MEASURE that prevents them from doing so. I think an acceptable compromise is to instead give users a way to express their wishes about how the data can be retained in the form of a "update this every n months/weeks/years/whatever" or a hard "expires on this date"-type rule. This way you acknowledge that there are indeed applications that need to retain user information for certain purposes and allow the user to have some control over this process. You could also put in a "don't retain this at all" flag, which in my forum case would probably cause the forum to just identify you by your raw OpenID identifier and have done with it. > By all means - include preventative code (and for some kinds of > attributes, digital time-stamped and signed assersions about the > attributes solve these problems). But I think it's a far bigger > mistake to completely leave out a server-to-server channel altogether. I have nothing against the server-to-server channel. In fact, the server-to-server channel is a prerequisite for the "update this every n months" thing because otherwise the RP would have no way to do that update. > When a rogue RP violates your trust and caches data without your > permission, that's bad. So a way is is needed for: * A trustworthy RP to indicate how long it would like to retain certain items of data * A user to indicate how long he would like certain items of data retained for, or how often the RP should try to refresh that data. * A way for the user to prevent further updates of a particular attribute by a particular RP after a certain date. The first and second points above would, I think, be helped by defining some reasonable defaults for each attribute type, just so that the average user doesn't necessarily have to spend ages entering update frequencies and expiry dates every time some attributes are requested for the first time. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
