[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?)

[Joseph Salowey <[e-mail]>]

I put together a PR (
https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/36/files) for
the architecture draft to try to better describe identity in a new
section.  Please comment and let me know if it helps. Other sections will
probably need to be modified once we tighten down this section.

Cheers,

Joe

On Tue, Jun 18, 2024 at 10:11 AM Justin Richer <[e-mail]> wrote:

> 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]
>
>
> --
> Wimse mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>