Extensible claims in JWT SVIDs

[lumjjb]

Following up on an action item from 09/17/2020 SIG-Spec meeting on the discussions on Extensible claims in SVIDs.

During the call, we discussed a couple topics around extensible claims in SVIDs, mainly around usecases, mechanism of extensible claims and several considerations in use.

Use cases

Labeling workloads to indicate an attested property

This usecase involves the ability to make authorization decisions on certain attested properties of a workload. This can be a logical aspect of the computation of the underlying workload, like the datacenter it is running in, or go into hardware backed claims such as ownership of a certain asset tag bootstrapped into a Trusted Platform Module. This way, authorization decisions can be made on geolocation properties and trust properties of the underlying compute a workload is running on.

This is helpful when authorization frameworks such as Vault Sentinel, or ABAC based auth/iam solutions allow creation of policies based on these claims. Having claims be part of the SVID makes extension of claims seamless and not requiring an additional structural schema definition (i.e. regexp on common name) that needs to be defined between versions of identity solutions and authorization of various services and apps.

Application specific use for logic, i.e. data/medical use case

Applications may choose to base logic on properties/claims of a workload identity. For example, in the data scenario, based on the type of workload running, as well as where the workload is running. For example, if a workload is in Europe, it would be given Europe based contextual information. A medical scenario was also mentioned around giving organization specific flows/data based on certain group and organization attributes of a workload.

Mechanism of extensible claims

We discussed the way the claims would be included in the SVIDs, the initial scope discussed was for the JWT SVID, as claim fields in the JWT. x509 was discussed as well, i.e. x509v3 ext. attributes, but was critical to the use cases presented in the near term.

Considerations in use

Claims collision and meaning

There was a worry about claim name collisions and what it they would mean. It was discussed that for JWT SVIDs. These would refer to the JWT RFC7519 Section 4.3) on Private claims. Use of the claims should follow the guidance from the RFC.

[evan2645]

thank you very much for opening this @lumjjb! we've been discussing it a little bit, and I think we've got some brainstorming to do on the best way to support it. We'll probably have some more questions in the coming weeks

[edwarnicke]

A couple of things to think about when looking at multiple claims:

1. It is very common to want to know in addition to who is making the claims what the claims are about and to whom the claims were made (think sub and aud in JWT)... these are of course also claims :)
2. You can easily imagine wanting to assert claims about claims made by others (and the necessary information to validate those claims).

So if @evan2645 claims he is in a particular room and also claims to me that he claims that I am in the same room with him, I may want to add that to the list of things I claim to @lumjjb to establish my location. I might want to add similar claims from others as well.

[edwarnicke]

Small list of possibly interesting claims:

1. Where a workload is running (ie, what Node in what Cluster, in what Cloud, in what Zone... which may involve a chain of claims).
2. What precisely is running (think has of container)
3. All the things running in a particular context (think has of all containers running in the same Pod)

Hmm... the more I think about this, the more this starts to feel like multiple chains of attestations...

[JackOfMostTrades]

In the interest of avoiding name conflicts and also managing concerns around claims for federated trust domains, should it be a requirement that claims be placed under a claim key matching the trust domain? E.g.

{
   "sub": "spiffe://acme.org/foo",
   "exp": 12345,
   "acme.org": {
      "claim1": ["a","b"],
      "claim2": "xyz"
   }
}

[JackOfMostTrades]

Also, I know x509 isn't in scope for this first pass, but it seems important that whatever allowances are made for extensible claims is compatible with x509. Support for that is a blocker for our adoption of spire, so I want to make sure assumptions don't go into jwt claims that make it hard to port to x509.

[lumjjb]

Are you thinking about x509 v3 ext attributes to put the claims in? or something else?

[edwarnicke]

In the interest of avoiding name conflicts and also managing concerns around claims for federated trust domains, should it be a requirement that claims be placed under a claim key matching the trust domain? E.g.

{
   "sub": "spiffe://acme.org/foo",
   "exp": 12345,
   "acme.org": {
      "claim1": ["a","b"],
      "claim2": "xyz"
   }
}

Interesting thought... but what if the trust domain is to broad a scope? You are basically advocating for a sort of namespacing for non-standard claim keys... which in the generic feels like a good idea... but scoping it to the trust domain requires agreement within the trust domain... which may be a very large scope...

[JackOfMostTrades]

Are you thinking about x509 v3 ext attributes to put the claims in?

Yea, if it was my call I'd choose an OID, choose some encoding scheme (JSON, CBOR, proto, ...), and pack claims into a x509 v3 ext under that OID.

[JackOfMostTrades]

but scoping it to the trust domain requires agreement within the trust domain... which may be a very large scope...

True, but SPIFFE IDs within a trust domain already have to worry about name conflicts. AFAIK the scope of managing names and avoiding conflicts inside a trust domain is left to users. I think claims can be thought of as the same way. If you are wanting to setup hierarchical names within a trust domain this still allows for that {"acme.org":{"suborg":{"claim1":123}}}

[edwarnicke]

but scoping it to the trust domain requires agreement within the trust domain... which may be a very large scope...

True, but SPIFFE IDs within a trust domain already have to worry about name conflicts. AFAIK the scope of managing names and avoiding conflicts inside a trust domain is left to users. I think claims can be thought of as the same way. If you are wanting to setup hierarchical names within a trust domain this still allows for that {"acme.org":{"suborg":{"claim1':123}}}

Good thought again... though it starts to offend the simple clean aesthetics of JWT a bit pretty quickly down that path. Will think a bit on if there's a pretty way to do it ;)

[dfeldman]

Hi folks, We actually had a user request this specific feature. The reason is to connect to a third-party service that uses JWTs with a specific claim, and can't easily be changed. They just need a fixed key-value pair (probably specified in the registration entry), not a dynamic value. They might be able to work around by having a custom service that takes SPIRE JWT-SVIDs, and mints new JWTs with the needed claim.

[edwarnicke]

@dfeldman So basically just a static addition to the JWT. You might want to consider something similar to the templating that was done for the K8s stuff... that would potentially allow folks to template (in addition to purely statically) using values from the broader system. Thoughts?

[dfeldman]

I agree that would be a good long-term goal! I think it would take a lot of work though -- especially making sure it can't be abused, and also trying to get feature parity for X509-SVIDs. I think in the short term it might be best to focus on fixed strings and grow from there.

[edwarnicke]

@dfeldman My concern is that fixed strings basically only solve this one use case. And would have a propensity if done in isolation to be done in a way that precludes other future use cases in this space.

[ajessup]

A similar use case to that @dfeldman noted is a user who wants to annotate each registration entry with 0-N "groups" from a set, which would be used during AuthZ in different systems - since the endpoints performing AuthN and AuthZ can feasibly map entitlements to a fixed set of groups, but not workload identities to groups.

[ajessup]

As an FYI, some digging through the sig-spec notes led me to this PR which provides some useful considerations when operators add their own claims to SVIDs (which for the most part they are free to do so under the SVID spec), but does not define in the specification how those claims should be encoded or interpreted, leaving that up to the SVID issuer to figure out how to encode the claims in a form consistent with the X.509 or JWT specifications.

[azdagron]

Adding extra claims to JWT-SVIDs will be possible with the proposed Credential Composer plugin. Closing this issue in favor of that.