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

[Justin Richer <[e-mail]>]

Thanks, Watson.

[ Chair hat off ]

Ah, monads, I should have known they’d crop up here eventually. :)

I agree that there’s a fundamental difference between "what something is" and "what something can do", and on top of that there’s also "what we call something". All the "something" in this case is a workload in its context.

In many cases, it’s tempting or even convenient to wrap these up together. After all, if I know who you are, then I should know what you can do based on that. And if your identifier — the thing I call you — gives me some of that information in a structured format, then all the better, right? This is a large part of the thinking behind the SVID concept - the name has some internal semantics that guide me towards understanding what to do with the thing that has been given that name. And this pattern has been hugely useful, since it lets you carry information about authorization through a system using something that I guarantee will be there, the identifier. That’s what I’m reading from that section in the WIMSE Arch draft — here’s a larger identity question that gets encoded into an identifier and used for authorization decisions.

But for me, WIMSE does represent an opportunity to tease this apart better than it has been in the past, while still allowing us to deliberately collapse things in cases where it makes sense.  I should be able to figure out that Jessie is cow #2 without naming her "Jessie.cow[2]". But then the question becomes, how do I carry that information? And more importantly for us here, how do I do that in a way that’s interoperable on some level?

And the question goes further, because I don’t believe that identifying the workload is where the security decisions stop. In fact, I think that’s just one input, and not even necessarily a required input, into an authorization decision. Much more important is the context of the request in which the workload is running. This goes beyond the identity of the workload itself and into the world that the identified workload finds itself in at runtime.

I am not going to pretend to have clear answers, but I do think there’s merit in pursuing these questions to find them. But that said, I do believe that there are several concepts that are separable here, which can sometimes be expressed together using the same element:

- an identifier for a workload that is readable by other workloads and systems
- the collection of attributes that uniquely identify a workload (the identifier being one of them), its "identity"
- the runtime context around a workload (request context being a big part of this)
- the set of computed access rights for a workload in a context

In my view, OAuth access tokens are just one input to the runtime context, but today they’re being used to express all of these things in different ways in different systems. I really do think that if we’re going to stop always conflating things, we need to work on fundamental differentiation.


— Justin

On Jun 17, 2024, at 7:59 PM, Watson Ladd <[e-mail]> wrote:

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

--
Wimse mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]