RE: [dix] Proposed Charter for DIX Working Group

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

> 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 hallam at gmail.com, 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
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix