Re: [dix] Proposed Charter for DIX Working Group

[John Merrells <MERRELLS at SXIP.COM>]

On 13-Jan-06, at 8:18 AM, Hallam-Baker, Phillip wrote:


> The charter is somewhat more detailed than is usual.

Yes... because of the topic, 'identity', I wanted to scope the
work down as clearly as possible.


> I am not sure that the term 'identity' is going to be understood by
> those who read it in the same sense as intended by those who wrote it.

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.


> 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'.


> 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.

> As I see it the problem divides up into two major parts,  
> authentication
> and attributes.
>
> I think that the DIX group should only address the authentication  
> part.
> There are already good standards based protocols for exchange of
> attributes, SAML for example. I don't see any value to revisiting that
> area, at the end of the day the issuer and the recipient of that
> information will both have to implement code. It is a back end office
> application that is going to require custom code whatever way you  
> slice
> it.

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.


> The other reason for avoiding attributes is that that is where all the
> rat-holes lie. The Liberty org has spent years working up business  
> rules
> to govern transfer of personal data through closely coupled bilateral
> agreements. The IETF is not a good venue for such discussions, it is a
> technical organization, not a legal one.

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.


> Where I think that we need to look at something different is on the
> authentication side. SAML has an authentication mechanism but it does
> not have quite the structure people seem to want to see.

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.


> The problem as I see it in the federated identity space is that  
> there is
> no simple, open federation protocol that allows a user to easily  
> use an
> identity across multiple sites that do not have prior interchange
> agreements (or rule book structure if you like) in place.

Yes, that's one of the things that's motivating this user-centric
identity movement.


> This is a very different application area to the one being  
> considered by
> Liberty. In bloggish applications I expect that the main application
> will be simply the authentication component, laying claim to an
> identifier.

Note that that's just one example of many.

Also that there is useful identity information associated with users
in the blogosphere. My icon for instance. These days every blog
or 'web2.0' website requests a URL to an image of me. It's making
the web a friendlier place :-)


> 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.


> The Internet has a billion users, the point of DIX is not to serve the
> most sophisticated 10%, it is to serve the least sophisticated. I  
> think
> that it is well worth a marginal increase in sophistication on the
> administrator side if we can reduce complexity for the end user.

Yeah, couldn't agree more.


> The term 'secure' is going to get pounced on by the security people.
> Don't be surprised if you are required to write a threat model.  
> Although
> the group is looking to be chartered in applications that will not  
> stop
> the security people weighing in. In fact it may well be considered  
> that
> the group should be under security.

Yes... good advice.


> 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'.

Thanks for your illuminating comments.

John




_______________________________________________
dix mailing list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix