On 23-Jan-06, at 12:00 PM, Lisa Dusseault wrote:
I'm going to use my own terms for the 3 parties here because my
confusion about the official terms is an appropriate subject for a
different mail but I can't quite bring myself to use them.
Yes, I'm not too fond of the 'identity gang' names.
Thus, my simplified network diagram which ignores proxies and
optional bits like talking to directories
Content
Server---------|
| |
| Identity
| Server
| |
Client---------|
OK
We can't mandate that the other party in the exchange implement
DIX over a particular transport. It's an implementation decision
between the user's client and the other party. We have the motivating
use cases of a VOIP phone or IM client to illustrate this.
Here you're talking about the communication between the client and
the content server in my diagram. That communication is almost
outside the scope of DIX. It's the communication that already
takes place over many, many protocols, not all of which DIX WG can
tackle.
Indeed.
My personal suggestion is that DIX should tackle HTTP
That's my preference, but I wanted to leave the option open in case
others wanted to tackle other protocols within this WG.
and add a new Authorization header type and WWW-Authenticate
capability token and associated parameters,
That'd sounds like a good way to do it.
and perhaps also tackle SASL for which I'm not qualified to suggest
how.
Me neither.
We could mandate the transport between the user's client and their
agent. HTTP perhaps... given its simplicity and ubiquity. I do
hesitate
though, because I'm sure there are use cases where that doesn't
make sense. For example my agent might actually be built into my
client so the transport is IPC or API. What use would that kind of
agent be?... well it could just be a local replica of my agent in the
internet. Hmm, is my local agent really just an agent of my agent
and therefore a non-principal party to the exchange. Agh. What if
my agent were on a USB key or a smart card? What would my
transport be then... I'm not sure... I suppose it could be HTTP...
Now you're talking about the communication between client and
identity server in my diagram. The identity server MUST support
one or more well-known protocols such that if I'm implementing a
client, I can count on being able to contact a standards-compliant
identity server if I'm willing to do the work. Of course a client
might go beyond that and implement other protocols to talk to the
identity server -- even proprietary protocols -- but that would
have to rely on capability discovery or provisioning in order to work.
Yes.
So let's say DIX required BEEP and HTTP (at random) as the REQUIRED
TO IMPLEMENT transports for a compliant identity server. This
doesn't necessarily solve all problems for all clients but it does
make it clear what the client implementor has to do.
Does a client have to be able to talk to every identity server in
existence though. Maybe, but I'm not sure... that's what motivated
me to start on the use cases. If I'm worrying for no reason then
I'd be OK with mandating one transport for identity providers
and clients.
We could state:
"To ensure interoperability between implementations we mandate
that the user's client and their agent must support at least DIX
over HTTP."
Yes, but even more important for the identity server to have
required-to-implement transports.
My terms confused you. The agent is the identity server, so I'm
saying the same thing there.
It's hard to be definitive about this without the use cases to refer
to...
I may be assuming the use cases, but I'll forge onward.
The last major line in the network diagram is the communication
between the identity server and the content server. Over this
link, REQUIRED transports are crucial and can be kept, I suspect,
to just one. All content servers that advertise support for DIX
delegated authorization MUST be able to communicate with the
identity server chosen by the client using this one transport. All
identity servers that advertise compliance with DIX MUST be able to
communicate with the content server chosen by the client using this
one transport.
A single mandatory transport is most crucial for this link because
both the content server and identity server are chosen by the
client or user, and the two servers commonly have no ability or
opportunity to do any provisioning or setup, and can only negotiate
over the wire after initially making some kind of blind connection
in one of the two directions.
Revisiting my simplistic network diagram:
Content
Server---------| = ONE TRANSPORT
| |
ANY = | Identity
| Server
| |
Client---------| = ONE/TWO TRANSPORTS or configure/provision
otherwise
Yes - good point.
I didn't include the protocol exchange between the content server and
the identity
server because I though there might be alternative solutions that
didn't involve a
direct connection. dmd1 does this to minimize the code and its
complexity at the
content server (it's some message handling and a hash function). But
an alternative
solution could do something more sophisticated.
I had a private email from somebody who took much the same position.
Does anyone else want to pitch in an opinion on this?
John
Lisa
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
