RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)

[Hallam-Baker, Phillip]

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.

The principle point of SAML was to devise an open standard that allowed
an ERP application to hook into the enterprise authorization system. If
you look at most of the authorization products on the market you will
find that 90% of the code is essentially interface drivers to all the
1001 applications enterprises need to run.

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. Typical applications are
allowing a traveller to have a single unified frequent flyer membership
account that allows interaction with all the members of a given network.
This means that all the thorny issues of business rules etc have to be
considered up front. 

What DIX is looking at is a much simpler problem. While some of the
companies involved are also looking to build enterprise strength systems
that may involve DIX and DIX protocols that is not where the working
group is starting from.


If you strip away all the fancy talk the problem and the solution here
are pretty simple. The only reson that it seems to be fancy talk is that
we are not yet familiar with the solution. It is exactly the problem
hypertext had before the web. I am sure that the Web would have been
invented five years earlier if hypertext had not had such a name for
hype.


The problem is that I have 100 od accounts at Web sites all over the
net. Each of these requires me to register separately and most ask me to
provide the same basic information. At the end I am left with the
problem of remembering all the accounts and passwords. Some people have
developed schemes for remembering the usernames and passwords but a much
better solution to the same problem would be to start with a single
identifier that represents 'me' at every site I visit [or multiple
identifiers if I choose].

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.

In order to use the identifier in the Web we will need to define a URI
scheme, I suggest dix:pbaker.verisign.com. Just as long as nobody
expects users to type in anything other than their email address (yes I
have given up trying to use a # mark as a separator to avoid spam). It
would also be polite to actually think about the I18N issues at the
start this time instead of afgter the fact like we usually do. 


Here we have a bunch of proposals as to how this can work. Most involve
HTTP referal schemes. Some people are using HTTP digest. Others argue
that we should use SAML.

For example we might strip out the domain name component of the
identifier 'verisign.com' and then do a DNS lookup for a TXT record at
_dix.verisign.com which might list the DIX authentication protocols
supported by verisign.com. We can then do an SRV lookup to find out the
location of the servers for each supported protocol.


I am sure that the security area gurus will insist that the resulting
protocols will be proof against man in the middle attack and do not
result in passwords being exchanged enclair. 

This is not a big problem, HTTP Digest did that in 1993 and if people
bother to read the earlier drafts you will find that it was even
proposed as a federation scheme back in 1996 at least. So any patent
troll hoping to make a few bucks by reading this message and rushing to
the patent office as has happened before is going to be disappointed.

Identity is a complex problem. What is being proposed here is to solve
one very small part of that problem. I believe that it is the critical
part however. Once you have a universal identifier all else follows.


I think that far from this being a doomed enterprise we will have
achieved significant deployment long before a WG is approved.

Like the Web this is something that should have been done years ago but
never happened because people did not understand the need. Who needs the
Web when you can get documents using FTP?


> -Original Message-

> I'm wondering what is the relationship of this proposed work 
> to SAML or the work of Liberty Alliance.
> 
> http://www.projectliberty.org/
> 
> I was frankly astounded that there is nothing in the Charter 
> Draft or associated documents that mentions the huge body of 
> work already existent on Federated Identity Management.
> 
> Could someone summarize the problem state

Re: udp source address change

[Masataka Ohta]

Wes Hardaker wrote:

> Protocols and implementations should generally respond using the
> address to which the request packet was sent.  That being said, there
> are sometimes protocol reasons not to do this and sometimes
> implementations don't necessarily handle things properly internally.
> But, I doubt most protocols ever specify the "legality" of what
> address is used to respond to a request.

RFC1035 says it a bug. So, it should be illegal.

   - Some name servers send their responses from different
 addresses than the one used to receive the query.  That is, a
 resolver cannot rely that a response will come from the same
 address which it sent the corresponding query to.  This name
 server bug is typically encountered in UNIX systems.

However, the "bug" is overcome by ID field provided in DNS.

SNMP is seemingly doing the same thing with request ID.

Masataka Ohta



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Knowing what BOFs are being thought about

[Spencer Dawkins]

I am not sure Dave's list is a complete list of stuff to remember, but it's 
definitely a list of stuff to remember.


I'm not quite sure where the discussion forum for 
http://www.ietf.org/internet-drafts/draft-narten-successful-bof-01.txt is, 
but I really like the collection of stuff to remember that it contains so 
far.


Not sure who has seen this draft yet, but if you've seen 00, 01 is an 
improvement, too. The change I like best was the breaking some steps into 
finer-grained "stuff" (we tend to tell someone "talk to the AD", and neglect 
minor points like what ADs look like, where to find them, how to know which 
one to talk to, etc.)


I'm not sure where comments on this draft are supposed to go (Brian and 
Thomas are talking), but if people wanted to start by reading 01, that would 
be pretty helpful, when the location gets figured out.


My understanding of the scope of this draft is that it's descriptive (makes 
recommendations for working in the current system). There's probably some 
reasonable changes to the current system that could be proposed, too, but 
that doesn't look like the focus, for now.


Thanks,

Spencer

From: "Dave Crocker" <[EMAIL PROTECTED]>


The current model for BOFs tends to view the first one as a free shot.  No 
history required.


Given how poorly such first meetings tend to go, I am at a loss to 
understand why this model persists. Remember that a BOF is for gauging 
community interest in the working group.  That simply is not possible when 
the topic has no meaningful IETF online history.


I am in the camp that believes that IETF meeting time is extremely 
valuable and that the IETF is still predicated on email list discussion as 
its primary venue(s).


As such -- particularly a BOF targeting working group formation -- we 
should require that a pre-wg BOF be required to have:


   a) formed an online discussion, some months ahead of any possible BOF

   b) its formation announced on ietf-announce

   b) put forward a sample charter on that discussion list

   c) conducted discussion of that charter, prior to the BOF.

That way, there is a basis for recruiting informed participation, as well 
as gauging a degree of community interest. 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Knowing what BOFs are being thought about [was: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)]

[Dave Crocker]

Elwyn Davies wrote:
Finding out what BOFs are being plotted is not very easy AFAIK.  In the 
case below there doesn't appear to have been any widespread public 
announcement of the start of the mailing list and I suspect that is the 
case for many others.


Obviously an announcement of intent to the IETF list or the Announce 
list is one way for people to tell the world. 



Indeed.

The current model for BOFs tends to view the first one as a free shot.  No 
history required.


Given how poorly such first meetings tend to go, I am at a loss to understand 
why this model persists. Remember that a BOF is for gauging community interest 
in the working group.  That simply is not possible when the topic has no 
meaningful IETF online history.


I am in the camp that believes that IETF meeting time is extremely valuable and 
that the IETF is still predicated on email list discussion as its primary venue(s).


As such -- particularly a BOF targeting working group formation -- we should 
require that a pre-wg BOF be required to have:


   a) formed an online discussion, some months ahead of any possible BOF

   b) its formation announced on ietf-announce

   b) put forward a sample charter on that discussion list

   c) conducted discussion of that charter, prior to the BOF.

That way, there is a basis for recruiting informed participation, as well as 
gauging a degree of community interest.


d/

ps. I suggest that the DIX BOF is a particularly good candidate for going 
poorly. Online identity has a history for which a description of "problematic" 
would be a vast understatement.  Even better, the IETF's track record in the 
arena of digitizing human constructs is, well, limited.


--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Knowing what BOFs are being thought about [was: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)]

[Elwyn Davies]

Finding out what BOFs are being plotted is not very easy AFAIK.  In the 
case below there doesn't appear to have been any widespread public 
announcement of the start of the mailing list and I suspect that is the 
case for many others.


Obviously an announcement of intent to the IETF list or the Announce 
list is one way for people to tell the world. For those who can't cope 
with the traffic on the IETF list and to provide a more permanent 
reminder, it would help to have a 'prospective new work' page on the 
IETF web site where new pre-BOF mailing lists could be publicised with a 
time limit so the advert is removed at the end of 1st or 2nd IETF 
meeting after it was first started (or when a BOF occurs or the WG 
starts up) to avoid the list getting overly long.


Regards,
Elwyn

Scott Hollenbeck wrote:

-Original Message-
From: Richard Shockey [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 10, 2006 10:39 AM

To: John Merrells
Cc: ietf@ietf.org; Ted Hardie; Hollenbeck, Scott; Lisa Dusseault
Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)

John Merrells wrote:


Name of the BOF
  
I dont see a preliminary discussion list on this BOF. That's IMHO is 
customary.



There's a list that's been around since approximately Vancouver.  Archives
included:

https://www1.ietf.org/mailman/listinfo/dix

I'll let John answer your other questions. ;-)

-Scott-


___
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: Request to the IAB for clarifiction of its Jan 31 IAB Response to Appeal from Jefsey Morfin

[Leslie Daigle]

Harald,


Indeed, the IAB response concludes that the IESG has not
given sufficient justification for its decision in
Mr. Morfin's appeal, and that decision has been annulled.

The IAB's role here is one of review (in the appeal), not
directing the actions of IETF process.

If you require further direction, I refer you to the IESG.

Leslie.

Harald Tveit Alvestrand wrote:

Hello,

as the person responsible for the mailing list in question on Jefsey 
Morfin's appeal that the IAB responded to on January 31, I have a 
question for clarification, which has an immediate effect on what this 
maintainer will do while this stuff is being processed.


Quoting from the IAB response, and trying to cover only the important 
facts:



The IAB interpreted this appeal to be as follows:

The appeal concerns whether the IESG, in upholding the suspension of Mr.
Morfin's posting privileges to the ietf-languages mailing list, made an
incorrect decision.




.we find there is no
specific mailing list management process RFC that applies.




While we find that neither RFC 3683 nor RFC 3934 directly apply
in this case, the IAB understands that the IETF must be able to
act in the face of ambiguity in "the rules." Indeed, it would be
a terrible outcome if we found the IESG's decision would have
been reasonable if neither RFC 3683 nor RFC 3934 existed, but now
unreasonable since the documents do exist but don't
apply.




Responsible parties
must be able to take action even if there is ambiguity or lack of
explicit coverage by specific process documents.




current list maintainer practice is only to block postings from
operationally-disruptive sources.




The IAB found that the response provided by the IESG in this
action did not provide sufficient justification to sustain the
banning of Mr. Morfin from the ietf-languages mailing list.




.the IAB annuls the
IESG's decision in this appeal and sends the matter back to the
IESG for resolution.



I can interpret this ruling in two possible ways:

- The IAB has ruled that the IESG has not given sufficient justification 
for its decision to uphold the suspension of Jefsey Morfin, and that 
such a justification cannot include reference to "rules that apply by 
analogy", but can only refer to "common and reasonable practice"


- The IAB has ruled that it is not permissible for a mailing list 
maintainer to suspend anyone from an IETF-related mailing list for 
anything but "operationally disruptive" reasons as long as there is no 
specific rule authorizing such an action


(A secondary question is whether offtopic postings can be considered 
"operationally disruptive" under the IAB's ruling. But if the first 
interpretation is correct, this does not matter.)


Since I cannot tell which of the two rulings the IAB intended to hand 
down, I cannot tell what the proper action for an IAB-respecting list 
maintainer is until such a time that the IESG determines that there is 
IETF consensus for a practice for mailing list suspension on IETF non-WG 
mailing lists.


I would appreciate a clarification from the IAB.

 Harald Alvestrand




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)

[Scott Hollenbeck]

> -Original Message-
> From: Richard Shockey [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 10, 2006 10:39 AM
> To: John Merrells
> Cc: ietf@ietf.org; Ted Hardie; Hollenbeck, Scott; Lisa Dusseault
> Subject: Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
> 
> John Merrells wrote:
> > Name of the BOF
> 
> 
> I dont see a preliminary discussion list on this BOF. That's IMHO is 
> customary.

There's a list that's been around since approximately Vancouver.  Archives
included:

https://www1.ietf.org/mailman/listinfo/dix

I'll let John answer your other questions. ;-)

-Scott-


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)

[Richard Shockey]

John Merrells wrote:

Name of the BOF



I dont see a preliminary discussion list on this BOF. That's IMHO is 
customary.


I'm wondering what is the relationship of this proposed work to SAML or 
the work of Liberty Alliance.


http://www.projectliberty.org/

I was frankly astounded that there is nothing in the Charter Draft or 
associated documents that mentions the huge body of work already 
existent on Federated Identity Management.


Could someone summarize the problem statement this proposed WG attempts 
to solve, more specifically what is lacking in existing Federated 
Identity Management efforts that the IETF may have some relative 
expertise in solving?




Digital Identity Exchange (DIX)

Area:

Applications

Chairs:

Lisa Dusseault <[EMAIL PROTECTED]>
John Merrells <[EMAIL PROTECTED]>

Sponsoring Area Directors:

Scott Hollenbeck <[EMAIL PROTECTED]>
Ted Hardie <[EMAIL PROTECTED]>

BOF Description

Objectives

1. To consider the creation of a new IETF working group within the 
Applications Area  titled "Digital Identity Exchange".  The proposed 
charter for such a working group is referenced below.


2. To discuss and hone the scope of a DIX working group.

3. To discuss the architectural requirements that derive from the laws 
of identity identified by ‘The Identity Gang’ at ‘The Berkman Center for 
Internet & Society, Harvard Law School’. Referenced below.


4. To discuss existing architectural implementations within the context 
of these requirements. An individual submission Internet Draft that 
describes one such implementation is referenced below, named 
‘draft-merrells-dix-00.txt’


5. To determine if there is enough interest and commitment to form a 
Working Group and if so to then discuss what the specific goals and 
milestones of that working group would be.


BOF Agenda

Introduction and Agenda Discussion (5 min)
Scope Discussion (10 min)
Identity Laws and Architectural Requirements (10 min)
Existing Architecture Presentations (30 min)
Call for Participation (5 min)
Deliverables Discussion (15 min )
Open Discussion (any remaining time)

Documents

Charter Draft: http://dixs.org/index.php/DIX_Charter
DIX Protocol ID: 
http://www.ietf.org/internet-drafts/draft-merrells-dix-00.txt

DIX Protocol ID: http://dixs.org/index.php/DIX_Protocol_ID
Identity Laws: http://www.identityblog.com/stories/2004/12/09/thelaws.html

___
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
 or

 ; 
<

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: udp source address change

[Wes Hardaker]

> On Tue, 7 Feb 2006 10:20:37 -0800 (PST), "mharrima101 (sent by 
> Nabble.com)" <[EMAIL PROTECTED]> said:

mharrima> Is the behavior of the HP switch legal under UPD?   It seems
mharrima> to me as though this should not be allowed.

Protocols and implementations should generally respond using the
address to which the request packet was sent.  That being said, there
are sometimes protocol reasons not to do this and sometimes
implementations don't necessarily handle things properly internally.
But, I doubt most protocols ever specify the "legality" of what
address is used to respond to a request.

Thus, what should happen is what you want.  In reality, as you
noticed, some implementations fail to do this.

-- 
Wes Hardaker
Sparta, Inc.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf