Subject: RE: [dix] Proposed Charter for DIX Working Group

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jan 2006 13:56:21 -0800

> What did it mean to you when you read it? My understanding, 
> and I think the general understanding, is that 'identity' is 
> a thing that a person has.

Not to be too picky but your definition seems pretty close to the
definition Douglas Adams suggested for 'life'. The same thing could
apply to his glasses should he be wearing them.

> > I prefer to use the terms 'identifier' and assertions concerning an 
> > identifier.
> 
> And, I think that 'an identity is identified by an 
> identifier'... and that 'attributes are bound to identifiers 
> by assertions'.

An identifier is a sign that stands for an identity.

> > I would also suggest that the application in the blog world is 
> > accountability based rather than permissions based.
> 
> I think that the user-generated content spam problem is 
> similar to the email spam problem. Initial solutions were 
> based on content analysis, but they have been defeated.
> There are now efforts afoot to identify the sender of an 
> email, so that the reputation of the sender can be 
> determined. 'Is the sender a good netizen?' The same problem 
> exists for user-generated content. So, I believe that 
> identity leads to reputation rather than to accountability or 
> authorization.

Reputation is part of the accountability approach. In slashdot you are
accountable to your reputation.

The three components of an accountability scheme are authentication,
accreditation and consequences. You have to have a way of knowing who to
hold accountable, you have to know whether you are likely to be able to
hold them accountable, you have to know that if they defect they will
face consequences.

Loss of reputation is one accountability strategy. However the SSL
scheme hangs together through the threat of legal consequences in the
case of a defection (at least with the high assurance CAs).

> Our thinking is that DIX provides a mechanism for moving 
> attribute assertions... those assertions could be about 
> authentication or about attribute values... and they could be 
> presented as plain text, or as XML, or as SAML, or whatever 
> the endpoints agree to exchange.

SAML is an XML format for describing attribute assertions.

The reason I think you need to think about SAML rather than plain text
is that in most of the cases that are interesting you are likely to be
dealing with assertions from more than just the authentication provider,
even though they might be distributed by the authentication provider.

For example I might have an account [email-masked], I might log onto
your blog and you might want to know what my Slashdot Karma is.

I think that the missing piece here is the identifier. Once you have a
common agreement on an identifier the other pieces fall into place.

> I'm in total agreement. We don't want to go down that 
> rat-hole. We have limited the scope to how the user moves 
> their own identity information from their agent to a relying party.

I would suggest less talk then that could be construed as being stuff
that you don't intend to do. I have just been involved in getting the
DKIM group chartered and you won't believe what people managed to get
wrapped round their axles...

> In the charter we've clearly stated that authentication 
> mechanisms are out of scope. The agent can authenticate the 
> user in any way it choses, and the relying party can chose 
> whether to accept that authentication or not. DIX just moves 
> the authentication assertion.

Where I think the system falls down today is the integration of the
various pieces. We have all the parts we need but none of them quite fit
together.

So I don't think you actually need to build any of the components you
describe, but you do need to get them to work together. 

I would however insist on a distinction between considering an
authentication mechanism and considering authentication. The group is
going to need to specify how to use at least one authentication
mechanism in the context of the chosen identifier.

What I would like to get to though is a framework that allows me to drop
in a new authentication mechanism without disturbing any party in the
ecology other than the user and their registry. 

> > The term 'simple' really needs to be qualified. Simple FOR WHOM?
> >
> 
> Good point. Perhaps I should have elaborated on that. In order
> of importance...
> 
> 1) The end user - easy to adopt, easy to use.
> 2) The relying party - easy to enable a site, easy to deploy.
> 3) The agent - all complexity is pushed to these guys.

I agree, but I would also divide 3 into two separate groups. Running a
registry of a thousand or so users and running a registry of a hundred
million are going to be two completely different things. I think that we
really want to say that we will try to make it easy to do a low end
registry without difficulty and make is possible to run a large
registry.

> > Finally I think that the charter must make clear that the protocol  
> > will
> > not involve the creation of any new registry. The Internet has one
> > federated namespace - the DNS. If DIX is to be an Internet 
> protocol  
> > then
> > the federation must be based on the DNS, either explicitly or
> > implicitly.
> 
> Yeah. The proposed charter states this:
> 
> 'The protocol should be inherently scalable, requiring no centralized
> services, beyond those that already exist, in order to operate.'
> 
> Perhaps oblique, but I meant what you said 'DNS'.

Actually I brought it up mostly because people seem to have some strange
ideas about what my motives might be in this area. 

However there are protocols that try to establish a new registry without
centralized services. I think it would be simpler to simply state that
partitioning of the name space will be achieved using the existing DNS
system.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Fri, 13 Jan 2006 14:56:45 -0800

> ecology other than the user and their registry.

Agreed.

I don't think that you need to specify any authentication mechanism  
if you say it is out of band from moving "identity"

---

From: Dick Hardt <[email-masked]>
Date: Fri, 13 Jan 2006 14:59:40 -0800

> even though they might be distributed by the authentication provider.

SAML is one way to make a digital assertion. Supporting SAML would be  
A Good Thing.

There are also lighter weight ways of making verifiable assertions  
that don't have the overhead, complexity and potential uncertainty of  
SAML. There are also IP issues there.

> common agreement on an identifier the other pieces fall into place.

Agreed

---

From: "Duane Nickull" <[email-masked]>
Date: Fri, 13 Jan 2006 15:09:49 -0800

We had a similar conversation in the OASIS WS-Security TC.  The TC
decided to build a modular set of specs to account for the addition or
use of various existing and future authentication mechanisms.  We have a
core WS-Security spec, then a series of profiles.

Currently Proposed 1.1 Specifications

    * SOAP Message Security 1.1
    * Kerberos token profile 1.1
    * Username token profile 1.1
    * X.509 token profile 1.1
    * SAML token profile 1.1
    * REL token profile 1.1
    * SwA profile 1.1

I would advocate a similar approach to preserve the core movement of
identity without worrying about what goes on in the black boxes.

Duane

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dick Hardt
Sent: Friday, January 13, 2006 2:57 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; John Merrells
Subject: [dix] Authentication out of scope

Agreed.

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 13 Jan 2006 16:20:57 -0800

I agree with this.  I got the impression from talking to Dick a while 
back, that DIX was going to leave a few very important pieces 
completely unspecified, which pretty much means no interoperability.

I would expect that the group would have to produce at least one 
technical (though not necessarily complete) Internet-Draft *before* 
getting chartered, rather than making those post-charter milestones.

lisa

---

From: Dick Hardt <[email-masked]>
Date: Fri, 13 Jan 2006 17:26:03 -0800

On 13-Jan-06, at 4:20 PM, Lisa Dusseault wrote:

> I agree with this.  I got the impression from talking to Dick a  
> while back, that DIX was going to leave a few very important pieces  

Not sure how that means no interoperability ... but I will wait to be  
enlightened on that!

> getting chartered, rather than making those post-charter milestones.

Agreed. We have thoughts here. :-)

---

From: John Merrells <[email-masked]>
Date: Fri, 13 Jan 2006 17:27:39 -0800

> apply to his glasses should he be wearing them.

Identity is a philosophical thing... i think people get that. 'Digital
Identity' seems to be the colloquial term people use for online
identity. I'm content that it means what I think it means.

> An identifier is a sign that stands for an identity.

Yes, we're in agreement. There's a paragraph in the charter that
explicitly points out that a fundamental thing to work out is what
an appropriate identifier is.

> case of a defection (at least with the high assurance CAs).

The text you're discussing is just an example. You seem to be saying
that there's a more general solution than the reputation one I'm
suggesting... fine... but for the purposes of an example I'd rather  
it were
more specific than more general. Yeah?

> wrapped round their axles...

What do you think is missing from the 'out of scope' section?

John