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

[Mingliang Pei <[e-mail]>]

I am new to this workgroup, and had just read the arch draft. This is a
very interesting topic. Thanks for the work. I have some questions that
might have been discussed in meetings or emails. Just a quick question that
kind of repeats what Pieter said, and please let me know if this has
already been well discussed.

>> 1. Identifiers: Identifiers are the basic building blocks of any
identity system. It is only possible to manage identities if there is a way
to identify them uniquely within and across trust domains.

I agree, and thought there would be some unique identifier to be associated
with a workload, and the spec defines patterns / standards how workload
providers may assign and register identifiers to its workload. Currently,
the "workload identity" is defined as a set of attributes where the
attribute names are open for a platform to define, at least, no
specific set is proposed yet. This sounds to me that further works are
needed to support some interoperability and interpretation (in validation,
authorization etc.)

Thanks,

Ming


On Tue, Jul 2, 2024 at 12:03 PM Pieter Kasselman <pieter.kasselman=
[e-mail]> wrote:

> Working group chair hat off, identity enthusiast hat on...
>
>
>
> Thanks for working on this PR Joe, this is a tricky subject ;)
>
>
>
> Someone once told me that the first trap to avoid when working in identity
> is to try and define it... It is hugely overloaded and we often end up
> using it as shorthand for a set of other more burdensome activities we try
> to describe.
>
>
>
> Another way to look at it is to focus on the outcome you expect from your
> use of "identity" and then define the building block to achieve the
> outcome. You never end up defining identity, but rather what you want to
> use identity for (the outcome), which in turn helps scoping down the
> building blocks.
>
>
>
> So, when it comes to things like using identity to decide access, a useful
> way to think about the reason for having identity is that you want to
> ensure that the right entity (person/workload/device) has access to the
> right resource at the right time for the right reason. To build such a
> system you end up needing a couple of building blocks. These include:
>
>
>
> 1. Identifiers: Identifiers are the basic building blocks of any identity
> system. It is only possible to manage identities if there is a way to
> identify them uniquely within and across trust domains.
>
> 2. Attestation: Attestation includes the presentation of proof to
> establish the provenance of an entity. This assertion may include a
> cryptographic binding (use of a cryptographic key or shared secret), but
> may also include the collection of other information to assert the
> provenance of the entity.
>
> 3. Secrets Management: Some entities use long-lived secrets such as
> cryptographic keys (symmetric and asymmetric) as part of the attestation
> process. In the case of asymmetric cryptographic keys, the public key may
> be included as an attribute in a credential (see next point on credential
> formats).
>
> 4. Credential Formats: Identifiers are often shared with other system
> participants by encapsulating them in a credential with a specific format.
> The credential may include additional information or attributes to identify
> the entity and is often bound to this additional information using
> cryptographic techniques (e.g. digital signatures). Examples of credential
> formats include X.509 certificates, JSON Web Tokens, and Verifiable
> Credentials.
>
> 5. Provisioning: Identifiers, attestation metadata, secrets and
> credentials follow a lifecycle that includes the usual create, read,
> update, and delete operations that are recorded in a system of record (e.g.
> a directory).
>
> 6. Authentication: Proving that an identifier and a set of additional
> attributes is associated with an entity. This is done by presenting a
> credential which may include attributes that the recipient can verify,
> including proof of possession of a private key matching the public key
> included as an attribute in the credential.
>
> 7. Authorization: Answering the question of “does this entity have access
> to that resource, at this time, under these conditions?” based on the
> previous 6 building blocks. It answers the original question, but there are
> a few more components needed beyond just making the decision around access.
>
> 8. Federation: Maintaining trust boundaries within a system is a common
> part of controlling access to resources. As an entity cross trust
> boundaries they need to be able to establish trust relationships to both
> accept credentials from other domains as well as have their own credentials
> accepted.
>
> 9. Monitoring and Remediation: Once an entity is authenticated and
> authorization decisions are made, it is necessary to monitor their activity
> to detect anomalies that may indicate compromise. If a compromise is
> detected or suspected, it should trigger remediation to mitigate the impact
> of a compromise.
>
> 10. Policy and Configuration: Policy and configuration is required for
> each of the machine identity building blocks. Policy defines the specific
> rules that should be applied, ranging from credential format through to
> authentication method and authorization rules.
>
> 11. Compliance: Compliance for each building block needs to be proven
> against the policies for that building block. Compliance often takes the
> form of reports and the process is simplified through the use of structured
> data in both the policy and the event logging.
>
>
>
> Looking at the PR, I wonder if, instead of defining a workload identity,
> what if you define a workload identity management system that ensures the
> right workload has access to the right resources at the right time? In that
> case you could define a workload identifier, credential format and some of
> the attributes included in the credential format (including a public key
> perhaps). Instead of having a “workload obtain its identity”, perhaps we
> might say that “a workload should be provisioned with a credential that
> includes an identifier and other attributes, along with any secrets it
> might need, as early as possible in its lifecycle”. Instead of “a workload
> presents its identity”, we can be more specific by saying “a workload
> presents its credential and authenticates itself using the private key
> bound to the credential to generate a signature and prove control of the
> key”. It’s way more burdensome and time consuming to say, but it could help
> avoiding overloading how the term “identity” gets over used (this may be a
> bit of an extreme example).
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
>
>
> *From:* Joseph Salowey <[e-mail]>
> *Sent:* Tuesday, July 2, 2024 1:52 AM
> *To:* Justin Richer <[e-mail]>
> *Cc:* Watson Ladd <[e-mail]>; [e-mail]
> *Subject:* [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?)
>
>
>
> 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]
>
> --
> Wimse mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.