[Wimse] What is an identity and section 3.2.1 of draft-ietf-wimse-arch (or must identity be the compositum of all attributes?)

[Watson Ladd <[e-mail]>]

Dear wimsyists,

I must confess to never having read Leibnitz, but I think section
3.2.1 will force me to. I hope this long rambling email explains why
and elucidates some of what confuses me in WISME, and hopefully others
find out they are likewise confused.

Section 3.2.1 implies the identity must include a bunch of information
that's relevant to the problem of authorizing a request, that is
conveyed by whatever ticket brings it alongside a request.

There are two notions of identity at play here. The first is the
concept that makes one thing not like the other. The other is the name
by which we might call a thing not like the other. E.g a farmer might
have cow 1, cow 2, cow 3, or Bessie, Jessie, and Daisy. Bessie does
not convey any of the relevant information about that cow, but does
identify it uniquely among the herd. To me this is also identity, and
indeed is the identity that would be most convenient to convey. This
is where Leibnitz comes in.

Now given a request we might want to evaluate the fundamental question
of "who get to do what to whom". And here I think the distinction
between authorization and authentication has been elided a bit.
Authentication only determines the who. Authorization is about
answering the question of if the request is in fact authorized. A
token could speak only to authentication, but it could also provide
authorization information. The draft is pretty ambivalent about which:
while there is a lean towards authentication it seems the token
issuance is also supposed to be a gating function, and the token
needing to carry more than a simple identifier means that it starts to
blur the line.

Lastly there's a huge gap for me around what sort of policies make
sense. Many systems I've seen and worked with had a broad class of
services provided by various elements, and the users of such services
might be a very dynamic set. Others had a self-serve partitioning of a
class of resources allocated to each service calling in. Other times
we might have systemic policies, e.g. "Infosec says all services must
do X, which we can determine at build time, and those that don't can't
run". Expressing these policies in human understandable form argues
for a simple identifier as a human readable policy depends on such
identifier. I don't think a complex identifier works for that.

In conclusion I think we need to make an explicit choice. Either the
token carries a workload identifier (akin to a Service in K8S or
something else?) or it carries a grab bag of attested environmental
attributes over which policies run. And I think we need to figure out
what policies should be expressable and which shouldn't be.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim