This email is getting closer to picking apart the different pieces of
the network architecture for delegated authority and considering
those pieces separately with respect to Scott's suggestion of certain
"required to implement" transports. I think we need to take it
further because each main line in the network diagram has to be
considered separately.
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. Thus, my
simplified network diagram which ignores proxies and optional bits
like talking to directories
Content
Server---------|
| |
| Identity
| Server
| |
Client---------|
On Jan 20, 2006, at 7:16 PM, John Merrells wrote:
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.
My personal suggestion is that DIX should tackle HTTP and add a new
Authorization header type and WWW-Authenticate capability token and
associated parameters, and perhaps also tackle SASL for which I'm not
qualified to suggest how.
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.
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.
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.
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
Lisa
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
