RE: Requirements Document

> >Sure. I agree. But this is 100% an implementation
> >and/or deployment issue,
>
> absolutely right (I'm not talking about UI here.)
>
> > and not a protocol or "object" issue.
>
> absolutely wrong. If we don't specify what is required to comply
> with a protocol (and specifying the object the protocol manipulates
> is part of the protocol), you have no interoperability guarantee.
There is a very big difference between specifying the object and
specifying the protocol. In some cases, the protocols exist already,
and may have the appropriate mechanisms for the use case. In others,
appropriate mechanisms may not be present and would have to be added,
but in all cases, the choice of mechanism, and even the requirements
of the mechanism depend on how the object is used, and not
on what it contains.

We can specify what it contains. We can write some broad requirements
on authentication and consent. What we can't do is specify a particular
set of mechanisms, or even specific requirements on those mechanisms
unless it is qualified by the field of use, and we must cater to
a very wide range of uses.

>
> >We can offer advice on the subject, but I can't see how
> >you would write anything stronger.
> >
> >I really DO want to use policy systems in some cases.
> >I really DO want to have delegation mechanisms in some cases.
> >I really DO want to have cryptographically secure authentication
> >in many (most) cases.
>
> So all these things must be in the protocol.
No, they MIGHT be in SOME protocols.
We aren't writing requirements for one protocol. We are writing
requirements for an object that will be used in several protocols.
Some of them may implement all of these, some of them may not implement
policy or delegation in any form. Some may have authentication that
is not accomplished cryptographically.

Consider a case where all the senders and receivers within a single
entity (enterprise). For example, I implement a smart badge that sends
my location continuously so that, for example, a hospital can find the
closest nurse to a patient.

There is no "authentication" of the receiver (the hospital).
It may be that the badge itself has crypto for authentication and privacy,
but
it's not the user. There is no explicit consent at the point of use - you
consent to have your location known when you accept employment, and location

is broadcast continuously. That is a useful system. We should allow such
a system to be built using our standards. That system has no explicit
consent, no explicit user authentication. It HAS authentication, and it
HAS consent, it's just not part of the protocol that transfers location.

Brian
Received on Tue Aug 21 09:39:20 2001