Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Steven M. Bellovin wrote: Actually, my bigger concern is privacy. I like to decouple the identity I use on different web sites I like to decouple the identity I use on different sessions with the same web site. (Depending of course on what the identity is used for. E.g., authorization to use a service vs. accessing something that belongs to me personally.) --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
-Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Sunday, February 12, 2006 9:14 PM To: Hollenbeck, Scott Cc: ietf@ietf.org; Ted Hardie Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX) My immediate concern is that we know better than to conduct this sort of BOF in this sort of manner. What sort of manner is that, Dave? That's a serious question. There is an open mailing list on which discussion has been taking place since the Vancouver meeting. Sorry. I missed the ietf-wide announcement of that list, made long enough ago to permit extended online discussion, as a lead-in to this BOF, to ensure consideration from a wide variety of perspectives. That discussion would permit the BOF to take place with enough community history to make it possible to have a productive BOF. (I thought I covered that concern in my previous note.) Anyhow, please point me at the announcement, since the mere existence of a list that few know about does not mean much. (Based on the list archive, and the comments emerging now, I am not the only one who missed that announcement.) I ask a serious question and I get a sarcastic reply. That's a great way to have a productive conversation. The proponents of this BOF are following the community's documented procedures [1]. What I'm hearing is that there is a underlying problem with the adequacy of those procedures. Maybe it would be more productive to update the procedures to include different guidance on just how far in advance people should be sending public announcements and where those announcements should be sent. The public announcement, sent Friday 10 February: http://www1.ietf.org/mail-archive/web/ietf/current/msg40478.html List described in a follow-up: http://www1.ietf.org/mail-archive/web/ietf/current/msg40481.html Yes, I do understand that these are the messages that you are claiming should have been sent earlier. We're just going to have to disagree about that. By the way, the IESG has started talking about the idea of automatically sending public announcements when new mailing lists like this one are created. That would be a good step forward. -Scott- [1] http://www.ietf.org/ietf/1bof-procedures.txt http://www.ietf.org/rfc/rfc2418.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Behalf Of Dave Crocker Reflecting on the various postings, so far, here is what seems likely to happen at the BOF: 1. We will get some presentations, explaining things that we should have read before coming to the BOF. You mean like people should read Internet drafts before making comments? 2. Audience participation will immediately bog down about a) related work, b) intended goals, and c) security risks. You mean that the face to face discussion will address the three principle issues that are relevant to the proposal. And that's why they need to be discussed *before* there is a BOF. The amount of time in a BOF does not permit real discussion, of the type called for, here. Good point, lets do away with all face to face meetings until the proposers are ready for last call. Given the particular nature, complexity, and controversy surrounding the topic of online identities, the second BOF will, at best, be only marginally more productive. This line of argument is somewhat insulting. If you do not understand the issues concerned then please by all means stay away until you feel that you understand them sufficiently to contribute. I usually take the view that if one does not understand something the best approach is to listen to people who might. In person presentations are considerably more effective for this purpose than email. While I cannot claim any significant experience in the field of 'identity' I think I can fairly claim to make a definitive contribution with respect to the question of prior work as the principle non-IETF works being cited all bear my name as editor. The proposal being made here is not in conflict with those initiatives and is complimentary in many ways. Phill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
My immediate concern is that we know better than to conduct this sort of BOF in this sort of manner. What sort of manner is that, Dave? I ask a serious question and I get a sarcastic reply. That's a great way to have a productive conversation. 1. You are right. My only excuse is that I felt/feel I had made two postings that largely already answered your question, and your query reflected none of that content. So the sarcasm was a reaction to having to repeat myself. See: http://www1.ietf.org/mail-archive/web/ietf/current/msg40484.html and, of course: http://www1.ietf.org/mail-archive/web/ietf/current/msg40496.html. 2. Other than having the opening tone be questionable, the note very much *did* provide content intended to be strictly productive. The proponents of this BOF are following the community's documented procedures [1]. What I'm hearing is that there is a underlying problem with the adequacy of those procedures. That's a worthy discussion, but my real concerns are the realities surrounding this type of BOF for this type of topic. In simplistic (but productive and non-sarcastic) terms, I think things reduce to the hurdles that an AD can/should impose prior to approving a BOF. Some topics warrant higher hurdles. There is ample basis for viewing DIX as one of them, IMO. I think the title of Thomas Narten's draft is particularly apt, because it focuses on productivity rather than formal process. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Perhaps it is just me but I find the two assertions implicit/explicit in your messages to be incompatible: 1) That identity is a topic that the IETF has failed to do useful work on in the past 2) That the organizers of the BOF have need of more extensive input from those who have failed to do productive work on the topic before proceding. While learning lessons from past failures is an important part of the design process this does not appear to be the type of input into the procedings that you appear to have in mind. It is reasonable to tell the builders of the new bridge to ask the architects of the old one why it fell down. It is completely unreasonable to tell the builders of the new bridge to ask the architects of the old one how to build the new bridge and wait on their reply. This BOF is not the only initiative underway in this space. The internet is under attack, phishing is a form of identity theft. So working out how to fit theft proof credentials into the Internet infrastructure is an important problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Monday, February 13, 2006 10:04 AM To: Hollenbeck, Scott Cc: ietf@ietf.org Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX) My immediate concern is that we know better than to conduct this sort of BOF in this sort of manner. What sort of manner is that, Dave? I ask a serious question and I get a sarcastic reply. That's a great way to have a productive conversation. 1. You are right. My only excuse is that I felt/feel I had made two postings that largely already answered your question, and your query reflected none of that content. So the sarcasm was a reaction to having to repeat myself. See: http://www1.ietf.org/mail-archive/web/ietf/current/msg40484.html and, of course: http://www1.ietf.org/mail-archive/web/ietf/current/msg40496.html. 2. Other than having the opening tone be questionable, the note very much *did* provide content intended to be strictly productive. The proponents of this BOF are following the community's documented procedures [1]. What I'm hearing is that there is a underlying problem with the adequacy of those procedures. That's a worthy discussion, but my real concerns are the realities surrounding this type of BOF for this type of topic. In simplistic (but productive and non-sarcastic) terms, I think things reduce to the hurdles that an AD can/should impose prior to approving a BOF. Some topics warrant higher hurdles. There is ample basis for viewing DIX as one of them, IMO. I think the title of Thomas Narten's draft is particularly apt, because it focuses on productivity rather than formal process. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
-Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 10:04 AM To: Hollenbeck, Scott Cc: ietf@ietf.org Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX) [snip] In simplistic (but productive and non-sarcastic) terms, I think things reduce to the hurdles that an AD can/should impose prior to approving a BOF. Some topics warrant higher hurdles. There is ample basis for viewing DIX as one of them, IMO. I think the title of Thomas Narten's draft is particularly apt, because it focuses on productivity rather than formal process. OK, that's a reasonable discussion point. Let me explain where I'm coming from in approving the request. I agree that this is a contentious topic. I explained the issues to several people when I was approached to hold a BOF at the Vancouver meeting. I didn't approve it then, primarily for the very reasons you've described. I approved the BOF this time not so much to consider a working group charter (note that the agenda does not include a review charter proposal item), but as an opportunity for the proponents to collect input from the broader IETF community in a high bandwidth environment after they have had a few months of discussion time to focus their proposal. There *is* a charter proposal floating around, but I personally believe (and list discussion seems to agree) that there are still a number of topics to explore before a charter can be seriously considered. I'm hoping that a BOF will help to identify those topics and other questions to be answered. In hindsight I probably should have recommended that the existence of the mailing list be announced much earlier. Earlier input from people like yourself, Steve Bellovin, and others who have shared opinions would be better. Since that didn't happen, though, my goal for the BOF is to try to capture a list of actions and issues for the proponents to consider as they developing their proposals. I fully expect that a second BOF will be required before a working group can be considered. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Hallam-Baker, Phillip wrote: Perhaps it is just me but I find the two assertions implicit/explicit in your messages to be incompatible: 1) That identity is a topic that the IETF has failed to do useful work on in the past That is a unfair statement. 1. There is lots of useful work being done on Identity Management its just not being done at the IETF. We are not the only standards body on the planet. 2. There is lots of interest in Identity all over the IETF specifically in the RAI area where there are several important drafts being worked on the relationship of SIP to SAML. I think this work extremely important. Are you familiar with the existent SIP SAML work? The question continues to be what areas _could_ or _should_ the IETF make a useful contribution on and how does that relate if any to the existing body of work on SAML and Liberty's Federated Identity Management work. I have some suspicion that W3C is also looking at this area. You were correct earlier post that the current work in Liberty has been oriented towards the enterprise single sign on problem but that does not mean it cannot be generalized to the cross domain problem that is the focus of the current Liberty Federation work. As everyone knows modern Identity management theory came out of the violent reaction to Microsoft's Passport proposal. I remain very cautious about reinventing the wheel here. 2) That the organizers of the BOF have need of more extensive input from those who have failed to do productive work on the topic before proceding. While learning lessons from past failures is an important part of the design process this does not appear to be the type of input into the procedings that you appear to have in mind. You incorrectly assume there are failures in this space. In fact there are several successes. I for one agree that the IETF has not looked correctly at Identity management in general but I also strongly believe the IETF has ignored the significant body of existing work in the space. It is reasonable to tell the builders of the new bridge to ask the architects of the old one why it fell down. I also do not want to build a new bridge if in fact the existing tunnels can handle the demand. It is completely unreasonable to tell the builders of the new bridge to ask the architects of the old one how to build the new bridge and wait on their reply. This BOF is not the only initiative underway in this space. The internet is under attack, phishing is a form of identity theft. So working out how to fit theft proof credentials into the Internet infrastructure is an important problem. Yes but what I and many others would like to see first better grasp of the problem statement, a survey of what is existent in Identity Management, a determination of what currently exists can be reasonably adapted to the problem ..then and only then attempt to design something new. There are lots of folks at IETF that are very familiar with Identity related problems and protocols. I am a bit disturbed that a solution is being proposed before the problem and the alternatives are throughly investigated. Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
On Sun, 12 Feb 2006, Dave Crocker wrote: Sorry. I missed the ietf-wide announcement of that list, made long enough ago to permit extended online discussion, as a lead-in to this BOF, to ensure consideration from a wide variety of perspectives. It might not meet your requirements for an ietf-wide announcement, but the announcement of the list and its topic was sent to the IETF list on 19 October 2005, with extended followup discussion. That discussion questioned how aggressive BoF-initiators should be in recruiting participants ... - RL Bob --- Date: Wed, 19 Oct 2005 16:28:05 +0200 From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Subject: Spam in the IETF's name? Found this one in my spam folder, and it made me wonder. 1) On first read (use of term IETF mailing list, use of term we without qualification), this sounds like an IETF-sanctioned activity. Is it? If not, who does John Merrels speak on behalf of? 2) Even if it is, is mass-like mailing (rather than sending to the IETF list, the IETF-announce list, or one-on-one personal mails) a reasonable way to recruit people? Harald -- Forwarded Message -- Date: 18. oktober 2005 01:36 +0100 From: John Merrells [EMAIL PROTECTED] To: (I have removed this list) Subject: Invitation to join the Digital Identity Exchange IETF mailing list Hello, We'd like to invite you to join the IETF mailing list for discussion of protocols and schema for exchange of digital identity information. For background information this keynote address delivered at OSCON 2005 presents the vision we wish to realize: http://www.identity20.com/media/OSCON2005/ And, these 'laws of identity' define the properties of an acceptable user-centric identity information architecture: http://www.identityblog.com/stories/2005/07/25/thelaws.html To subscribe to the mailing list send an email with the message body 'subscribe' to: [EMAIL PROTECTED] In addition there will be a meeting held at the next IETF, November 5-11 in Vancouver. This will be an opportunity to discuss digital identity issues face to face, and to consider whether the IETF should formally consider protocols for exchange of digital identity information. We'd like to welcome you to join us in Vancouver for that conversation. John Merrells ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
There are lots of folks at IETF that are very familiar with Identity related problems and protocols. I am a bit disturbed that a solution is being proposed before the problem and the alternatives are throughly investigated. Right. Some IETF work items involve narrow topics that are well-understood and have a core of interested folk who are clear about both of these facts, and clear about their goals. Other work items are not so lucky. As part of our efforts to ensure timely, useful output, we should work pretty hard to assess likely risks for IETF work, from before its inception (and on an on-going basis, of course.) Some items are clearly *very* important and *very* risky. They warrant pursuit but they are prime candidates for wasting the IETF's time. So they require extra efforts to find ways to make things be both timely and productive. At the very least, a wasted BOF consumes an expensive slot and delays the topic by at least 4 months. Note, however, that the opportunity costs associated with a BOF that is a public debacle can, in fact, have strategic impact, essentially poisoning the IETF waters. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
In hindsight I probably should have recommended that the existence of the mailing list be announced much earlier. Earlier input from people like yourself, Steve Bellovin, and others who have shared opinions would be better. Since that didn't happen, though, my goal for the BOF is to try to capture a list of actions and issues for the proponents to consider as they developing their proposals. Such as, Is existing work on Identity Management such as SAML, Liberty etal relevant to the problem statement as defined? How should a proposed solution integrate with the needs of the RAI area where this topic is under active discussion? That for a start ..please add to this if necessary. I fully expect that a second BOF will be required before a working group can be considered. On this I'm in complete agreement. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
From: Richard Shockey [mailto:[EMAIL PROTECTED] Hallam-Baker, Phillip wrote: Perhaps it is just me but I find the two assertions implicit/explicit in your messages to be incompatible: 1) That identity is a topic that the IETF has failed to do useful work on in the past That is a unfair statement. 1. There is lots of useful work being done on Identity Management its just not being done at the IETF. We are not the only standards body on the planet. Just to make clear, what I was objecting to was Dave's constant talking down what is known about this and other subjects by others. I was certainly not endorsing his assertion, merely presenting an iminent critique of his argument. I am pretty sick of the asgument 'we do not understand this problem, we must be cautious, therefore it would be a big mistake not to do it my way'. The term 'we' really meaning 'you'. I think that when you have a big problem you need to have people with a big enough ego to solve it. People who see only pitfalls and problems may provide useful input but nobody can solve a problem until they understand it. Are you familiar with the existent SIP SAML work? Not really, but I am familiar with SAML having been the first editor of the core spec. I don't claim exclusive insight into SAML but I think I can fairly claim some knowledge of the subject. I think that one aspect of the DIX proposal has the potential to unlock the whole field in the same way that the URL opened up the Web. Once you decide that you are going to have one identifier for a person and the semantics of that identifier are going to be uniform across the Internet all the pieces of the existing federated auth designs that I have felt are somewhat disconnected and 'squishy' become clear. The question continues to be what areas _could_ or _should_ the IETF make a useful contribution on and how does that relate if any to the existing body of work on SAML and Liberty's Federated Identity Management work. I have some suspicion that W3C is also looking at this area. Actually several of the people in this thread are on the organizing committee of the W3C workshop. That is not necessarily going to overlap, we have to see. Phishing is theft of credentials through a social engineering attack. One solution to the problem is better outbound authentication mechanisms (bank to customer) to defeat the social engineering attack. Another solution is better inbound credentials (customer to bank) that are theft proof. I think that it is clear that both problems have to be addressed. It is also clear that W3C is much better placed to address the user interface related issues of outbound authentication. The IETF as a rule avoids that area. So that is an item I very much hope that W3C will take up. The question of inbound credentials is not how to make the credentials theft proof, plenty have solved that problem. The question is how to use theft proof credentials in the existing Internet infrastructure. How to make them snap into use. This is not the problem that DIX is intended to solve but it is a problem that DIX provides a solution for. Federate the authentication scheme so that the identity holder chooses their own identity broker and all things become clear and possible. With DIX unified identifiers in place I can see how I could choose an identity broker that supports a strong authentication scheme of my choice (biometric, PKI, OTP) and use it with a range of sites without each web site having to take special steps. You were correct earlier post that the current work in Liberty has been oriented towards the enterprise single sign on problem but that does not mean it cannot be generalized to the cross domain problem that is the focus of the current Liberty Federation work. As everyone knows modern Identity management theory came out of the violent reaction to Microsoft's Passport proposal. Violent? I don't recall any Microsoft offices being burnt down or ransacked. Must have missed that bit. I remain very cautious about reinventing the wheel here. As one of the inventors of the wheel allegedly being reinvented I see this more as an essential refinement on the wheel, the axle perhaps. You incorrectly assume there are failures in this space. In fact there are several successes. I for one agree that the IETF has not looked correctly at Identity management in general but I also strongly believe the IETF has ignored the significant body of existing work in the space. As I said, I was anoyed at the argument 'we do not understand this, therefore the group must listen to us'. My experience is that when someone says 'we do not understand this' what they really mean is 'you do not understand this you great ignorant oaf but I do and I am going to try to force you to admit the fact of your ignorant oafishness by forcing you to either agree with my statement or appear to be suffering from meglomania.' Of course in the
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Behalf Of Dave Crocker Some IETF work items involve narrow topics that are well-understood and have a core of interested folk who are clear about both of these facts, and clear about their goals. Other work items are not so lucky. So it would appear to be a good idea to hold a BOF to decide which of these categories this particular problem falls into. As part of our efforts to ensure timely, useful output, we should work pretty hard to assess likely risks for IETF work, from before its inception (and on an on-going basis, of course.) That is the type of decision I am happy for the Area Directors to have made. Some items are clearly *very* important and *very* risky. They warrant pursuit but they are prime candidates for wasting the IETF's time. So they require extra efforts to find ways to make things be both timely and productive. So far it appears that at least 15 of the 50 or so people most closely involved in this space over the years (SAML, Infocard, Identity 2.0) will be attending the IETF for the sole purpose of attending this particular BOF. At least another 10 were planning to attend anyway. That looks like critical mass to me. At the very least, a wasted BOF consumes an expensive slot and delays the topic by at least 4 months. 15 * $650 = $9750, should be enough to cover the room hire. Note, however, that the opportunity costs associated with a BOF that is a public debacle can, in fact, have strategic impact, essentially poisoning the IETF waters. Given that this community is already familiar with working in OASIS, Liberty and OATH and a workshop is planned in W3C it would appear to me that far from being premature that the IETF would risk missing an opportunity here if it does not act. In retrospect it seems that the reason we did not address these issues in the SAML group was that we did not feel we had sufficient leverage in that forum to deploy a uniform identifier. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Knowing what BOFs are being thought about
For any document, you can always send comments to the author(s)... and so far, I believe I've been quite responsive to comments... But if you want to post publically, here (the ietf list) is as good a place as any, since the document isn't associated with any WG. i.e., for draft-narten-successful-bof-01.txt. Thomas Frank Ellermann [EMAIL PROTECTED] writes: Spencer Dawkins wrote: if you've seen 00, Yes, it could be referenced in the next procdoc-roadmap and the next taobis (-04 was published the day before yesterday). I'm not sure where comments on this draft are supposed to go If you find it out please post it here (dito for taobis, for procdoc-roadmap it's probably pesci). Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Steven, There's a certain (very much non-zero) cost associated with announcing _anything_ very widely. Generally it means the person making the announcement has to subscribe to the list (and hope the list manager does not filter the announcement anyway) - in part so that it will actually get posted and in part to capture comments made on each list that do not also get posted to an appropriate list (no matter what the announcement says, this will happen). In addition, there have been complaints in the past to the general use of cross-posting, and some list managers may even be actively filtering (for moderation in any case) on the basis of these prior complaints. I suspect that posting it to the IETF mailing list must be considered sufficient, with the understanding that people who care are subscribed to this list. Better to expect people to subscribe to this list to find out about stuff like BoFs and new mailing lists than to declare open season on all mailing lists. If others, who already subscribe to additional lists, want to repost these on those other lists (as an FYI, because they feel they are relevant), that would take care of widening of the potential audience. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Steven M. Bellovin -- Sent: Sunday, February 12, 2006 9:11 PM -- To: Hollenbeck, Scott -- Cc: Ted Hardie; [EMAIL PROTECTED]; ietf@ietf.org -- Subject: Re: IETF 65 BOF Announcement: Digital Identity -- Exchange (DIX) -- -- In message -- [EMAIL PROTECTED] -- .com, Hollenbeck, Scott writes: -- -- -- What sort of manner is that, Dave? That's a serious -- question. There is -- an open mailing list on which discussion has been taking -- place since the -- Vancouver meeting. There is still a month to continue -- discussion before -- Dallas. If something is too broad or not clear, please share your -- thoughts on the dix list so that appropriate changes can -- be considered. -- -- -- I think Dave has a point. It's not that there should be an active -- mailing list first -- ADs generally require a list and an -- I-D first, -- per RFC 2418 (a pointer to which should be in -- http://www.ietf.org/ietf/1bof-procedures.txt). The problem is that -- most people don't know about BoFs. I might be interested -- in tracking -- this one, but I learned of it only through John's voluntary -- posting to -- the IETF list. I agree with Dave -- BoFs should indeed be -- posted to -- the ietf-announce list as soon as they're approved. (By the same -- token, people proposing BoFs should announce their mailing -- lists quite -- widely. This one, for example, should have been sent to -- the SAAG list, -- among many other places, given the strong interest many -- security folks -- have in such issues.) -- -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
[EMAIL PROTECTED] said: While the members of the [dix] list appear to be reaching consensus on an approach, I don't believe that's the case at all on the dix@ietf.org list. I think there have been a fair number of concerns raised there -- so far inadequately addressed by the BoF organizers -- especially with respect to prior related work. So far the draft charter appears to be adroitly crafted to match the hawked input document, imho. JeffH ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
As the editor of SAML 1.0 and someone who will be a panelist on the Liberty panel at RSA next week the answer is DIX is solving a very different part of the same problem space. I disagree. SXIP (nee DIX) is overall attempting to solve essentially the same problem space that the SAML web browser SSO profile addresses. The extra aspects defined in the DIX I-D, which are largely various named attribute-value pairs, could be defined on top of the SAML web browser SSO profile (see saml-profiles-2.0-os.pdf at http://docs.oasis-open.org/security/ saml/v2.0/). Hence many of the questions and objections raised on the DIX list in terms of why reinvent the wheel??. The principle point of SAML was to devise an open standard that allowed an ERP application to hook into the enterprise authorization system. That's incorrect. I was there from the beginning too. We did not do any special tailoring of the SAMLv1.x specs to make them particularly complementary to any particular form of web-enabled app. Any vanilla website can be SAML-enabled by dropping in one of a plethora webserver plugins available from F/OSS sources thru your friendly for-profit software vendors. Liberty is addressing a slightly different part of the same enterprise federated identity space. In this case the identities being managed may be consumer identities but the exchange of information is typically taking place within a commercial context. This is also incorrect. The early liberty architecture overview did attempt to illustrate the problem domain with cross-business-enterprise examples, for better or worse (I, by the way, wrote that doc), but there is *nothing* in the protocol specifications that limit their applicability to strictly business contexts. At the moment there is some debate as to what that identifier should be. Most people in the group are proposing it should be a URL. As far as I am concerned we have an identifier already: [EMAIL PROTECTED] That's it. Now when I go to any site on the net I want to be able to first give my universal user identifier. Then have some magic happen so that I can safely authenticate myself against the universal authentication service of the domain name specified in my identifier. This can be accomplished using SAML. SAML, as you note, doesn't stipulate a particular identifier format. However, it is a small matter of crafting a new SAML profile that does stipulate one, and you will have what you're interested in. I nomially believe the DIX I-D could be recast as a SAMLv2 profile, fwiw. Hence, again, folks wanting to know why we need to specify something new protocol-wise, because that work's largely already been done. [EMAIL PROTECTED] said: While I cannot claim any significant experience in the field of 'identity' I think I can fairly claim to make a definitive contribution with respect to the question of prior work as the principle non-IETF works being cited all bear my name as editor. Only the SAMLv1.0 core spec does, and you share the editor billing with Eve Maler. You did not actively edit SAMLv1.1 nor SAMLV2.0, nor actively contribute to their development. It appears from mailing list archives that your active participation in the OASIS Security Services Technical Committee tapered off in summer/fall of 2002. SAMLv2 supersedes v1.x and is substantially different in various aspects, e.g. explicitly supporting the notion of identity federation, refined assertion schema, richer notions of protocol bindings and profiles, richer set of pofiles, etc. [EMAIL PROTECTED] later said: The question of inbound credentials is not how to make the credentials theft proof, plenty have solved that problem. The question is how to use theft proof credentials in the existing Internet infrastructure. How to make them snap into use. This is not the problem that DIX is intended to solve but it is a problem that DIX provides a solution for. Federate the authentication scheme so that the identity holder chooses their own identity broker and all things become clear and possible. this could be accomplished via a specific profile of SAML. With DIX unified identifiers in place I can see how I could choose an identity broker that supports a strong authentication scheme of my choice (biometric, PKI, OTP) and use it with a range of sites without each web site having to take special steps. the notion of a global identifier scheme is also being developed by various folks, notably the OASIS-based XRI (eXtensible resource identifiers) tech committee... http://www.oasis-open.org/committees/xri/ .. (which is on v2.0, and undergoing deployment) so any effort along those lines would also need to carefully evaluate/address prior related work, imv. JeffH ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
It might not meet your requirements for an ietf-wide announcement, but the announcement of the list and its topic was sent to the IETF list on 19 October 2005, with extended followup discussion. Although it is a bit strange to have a pre-wg mailing list run on the ietf.org server, with a closed invitation list, that doesn't really seem so terrible to me. Seeding initial discussions in this way could be useful to get initial discussions started, but with some chance of coherence. But that is strictly as a pre-cursor to an open announcement, of course. So I think we are back to the concern that the open announcement needs to be earlier enough to allow serious discussion prior to holding the BOF. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
BCP0115 RFC 4395 on Guidelines and Registration Procedures for New URI Schemes
A new Request for Comments is now available in online RFC libraries. BCP 115 RFC 4395 Title: Guidelines and Registration Procedures for New URI Schemes Author: T. Hansen, T. Hardie, L. Masinter Status: Best Current Practice Date: February 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 31933 I-D Tag:draft-hansen-2717bis-2718bis-uri-guidelines-06.txt URL:http://www.rfc-editor.org/rfc/rfc4395.txt This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... --ec0fca45c4ebdaf9a53a958d4158ebbd A new Request for Comments is now available in online RFC libraries. BCP 115 RFC 4395 Title: Guidelines and Registration Procedures for New URI Schemes Author: T. Hansen, T. Hardie, L. Masinter Status: Best Current Practice Date: February 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 31933 I-D Tag:draft-hansen-2717bis-2718bis-uri-guidelines-06.txt URL:http://www.rfc-editor.org/rfc/rfc4395.txt This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4394 on A Transport Network View of the Link Management Protocol (LMP)
A new Request for Comments is now available in online RFC libraries. RFC 4394 Title: A Transport Network View of the Link Management Protocol (LMP) Author: D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou Status: Informational Date: February 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 18 Characters: 40812 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ccamp-transport-lmp-02.txt URL:http://www.rfc-editor.org/rfc/rfc4394.txt The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to \'discovery\' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... --fff5458a34bc0b88a42823f425b00169 A new Request for Comments is now available in online RFC libraries. RFC 4394 Title: A Transport Network View of the Link Management Protocol (LMP) Author: D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou Status: Informational Date: February 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 18 Characters: 40812 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ccamp-transport-lmp-02.txt URL:http://www.rfc-editor.org/rfc/rfc4394.txt The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to \'discovery\' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining
