WIMSE Interim Meeting

Date: January 14, 2025
Note taker: Justin Richer and Hannes Tschofenig

Justin and Pieter started with a short welcome speech and working group
information.

WIMSE Architecture

new content since last time

• scenarios
• acknowledgements/thanks

Scenarios

most of the new work is in the (new) scenarios section

• common interactions in a workload environment
• will bring out some of the other things that are being worked on
  (s2s, token exchange)

Scenario 1: Basic workload identity scenario

• everything inside a trust boundary
• how workloads themselves get their credentials

Flemming Andreasen: The additional information is definitely helpful.
Workload 1 and 2 could be totally different services. Do we want to say
what constitutes the same services? What identity information do we need
to carry forward?

Joe: WL 1 and 2 could be the same software and just different instances.
For authz purposes we may not care whether we go through WL 1 or WL 2.
In other cases we may care what instance was executed at a given point
in time. There is an authz identity and this would be good to make this
distinction. This makes your other comments a bit clearer as well.

Mark Novak: I work on Confidential Computing and we want to make this
compatible with CC. In many cases you will rarely go directly to a
specific workload but rather through a gateway. We have to figure how
this works. When an app talks to the gateway it should not know about
the details how the service is decomposed but the security properties
have to be ensured. You terminate TLS at the gateway but the gateway has
to convince the WL that the it has the right credentials but also that
it is running the right software.

Joe: CC is dealing with identity of software, maybe we can leverage
that. Idenity of workloads as they talk to each other is what we're
looking at.

Mark: ID of workload and client can both be important.

Yaron Sheffer: Two points. It would be more consistent to talk about
WIMSE identifier or identity and not to define different levels of
identities (cluster identifier, instance identifiers). It is better to
define one level of identity/identifier and to talk about the
properties. IMHO we should not let CC define the WIMSE architecture. CC
is complicated and only one use case of WIMSE. There is tons of complex
with CC identity, which we do not want to dive into. Example: I have a
cluster of three instances of the same software and I update one part of
it to a new version.

Joe: Good to take this into consideration. If we define what WIMSE
identity is then we should also say what it is not.

Yaroslav: Without going into the details, we also have the term
"context" to signal additional information. @Mark: if there are specific
conflicts then it would be good to raise those in Github issues.

Mark: I definitely do not want to rathole the discussion but I guess
there is an incomplete understanding of CC identity.

Pieter (as individual): We should be careful about how we use the
identity terms in general. If we talk about a credential then we should
be specific. It is convenient to talk about "identity" but it leaves so
much room for interpretation. Just avoid that trap what identity means
in general.

Gateway receives the request and forwards it to the workload, workloads
work with each other. This is a relatively simple scenario but makes
things more concrete.

Scenario 2: Context and Workload Identity.

• when a request comes in to an application, some authentication
  happens (e.g. OAuth or OIDC)
• application will have an access token it can use to make a request
• when the token is processed, some service takes in the access token
  to create workload context (user, tenant, group)
• see OAuth WG Transaction Tokens work
• workloads use the context to perform authorizations and other
  functions

Flemming: When I was reading this, it was pretty abstract. In your
presentation now you provided more details and maybe you could more
details in the write-up for this scenario. Are we going to focus only
stay within the scope of the current WIMSE work?

Joe: we are scoped to WIMSE work, don't want to get too far away from
that, but WIMSE is being applied within a larger system. Maybe we should
use the term "transaction tokens" to refer to the work in the OAuth
working group. I do not have a clear line to draw. We have to work
through this as a group.

Pieter (as individual): The context service, do you envision something
bigger than the transaction token service?

Joe: Today, I do not know anything about a transaction token service. I
think it is a more general concept and I have to think more about the
transaction token concept.
I do not know whether we need to make the differentiation in the draft.
I was trying to generalize it.

Pieter: This makes sense. To generally describe the context and then
reference the transaction token concept as an instantiation of it.

Hannes: this will work on the edges not currently defined in the current
work

Joe: Context is squishy as well, we want to define and convey in the
architecture. We could have done a better job in referencing the
existing work.

Andrew McCormick: With the context service, you could deal with posture
assessment information.

Joe: that would be a good question, also for CC and other places, can we
put that into the arch as a generic service? There's reason to keep this
as a general concept, but we probably want to be specific about examples
(posture assessment and other attestations). Some services might be out
of scope.

Joseph Jubinski: Is the context service an overarching concept to the
transaction token service? Would it exceed the life of a transaction?

Joe: That is a good question. The transaction token has a lifetime of
the transaction. That token may have a use after the transaction is
over, for example with auditing. At some time in the workload process,
do we need specific constructs to deal with the asynchronous processing?
Example: scheduled batch jobs, long-lived transactions. This may require
some form of impersonation (acting on behalf of). These types of
interactions may be triggered via some other events rather than the
applications.

Scenario 3: Cross-domain communication.

• a bit more complicated, but more complete
• fairly common, lumps two scenarios together (maybe it needs to be
  split?)
• workloads need to talk to things in a different trust boundary
• might need a different type of credential
• might need to talk to a token service (different from a context
  service, might also need a context token as well)
• workload 2 doesn't want to disclose information of the internal
  environment, could need additional information, etc
• complication: there's a chained identity draft in OAuth that
  discusses a lot of these issues, will probably align with this

Kelley: I am co-author of the identity chaining / cross domain draft in
OAuth and I believe it addresses many of the scenarios you talked about.

Joe: use case is similar, goals might be different

Michael: The token service is producing an access token to access an
external service. This is strange that the token service is within the
trust boundary. Why is this not somewhere else?

Joe: This is the scenario where you have both - the internal token
service translates the token into a format that is usable for services
that are external service. I think this is something that is done today
but I am not sure whether it is the best approach.

Michael: is there a back and forth? does this token encapsulate a
credential? Is there a challenge-response?

Joe: probably?

Michael: external service passes a nonce to WL2, requires freshness

Joe: typically no, that's not a thing in these transactions. Round trip
is usually avoided for performance/convenience reasons. Would it be
better with it? Sometimes yes but it's not how it works.

Michael: there are other ways to get freshness, like times on the token.

Joe: tokens usually have issuance and expiration which solves many
problems.

Flemming: You covered it pretty. Totally agree with the scenario. I do
not think the token exchange is the core piece but rather the
cross-domain.

Joe: Where the token service is located is a core piece and people on
the call have thought through this.

Pieter (as individual): might be interesting to look at identity
chaining draft and reuse language for consistency. likewise to the
transaction token. are specific to oauth but show as "as an example of"

Joe: that gives us one concrete example, shows us we're on the right
planet

Gateway service (Yaroslav)

• new concept (not consistent with terms yet)
• separation between two domains
• propagates context
• access control for requesters
• routing and identity/path for request

request to WG: please look at wording and see where we could improve

Andrew McCormick: I have some thoughts on the gateway service and have
built similar components for retail edge machines at Starbucks. I'll set
some time aside to contribute to that topic in git.

Remote attestation (Hannes)

text isn't in the document yet, wanted feedback from the WG to begin
with

introduces "workload platform" in addition to workload (not just the
host), needs to talk to credential issuance

• platform needs to verify that workload is legitimate
• only legitimate workloads get credentials
• credential is used as an assertion for an authorization server in
  OAuth

One model

• when remote attestation, (RATS provides terminology) some
  information comes from lower layers
• agent relays this information
• agent gets credential
• agent sends workload credential

confidential container

• subsumes agent "inside" the workload
• still needs to obtain evidence from lower layers

is it useful to include?