WIMSE - IETF120

Notetakers:

• Supporting: Jeff Lombardo, George Fletcher

Welcome - 5 min (chairs)

Justin and Pieter introduced
Second Edition of WIMSE

AI generated logo / introduction to the WG group works

2 drafts in flight plus readouts from the design teams

WIMSE has a Mailing list and Github, please join

Current WG documents:

• WINMSE Architecture
• OAuth2 Client BCP document

Kudos to the Design team for work on Token Exchange and Service to
Service security (round of applause)

WIMSE Architecture - 20 min (Joseph Salowey)

• https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/

• Status update

Need to deep dive more on Workload Identity, will have a session today
on this

• WIMSE identifier

Group is trying to not focus on the general aspect of identity but focus
on an identifier as it is core to WIMSE.

Need to define "what is a workload"

WIMSE identifier is a URI, same basic format as SPIFFE

Needs to work closely with credentials, facilitate inserion in JWT X.509

Define a scheme, trust-domain and path
<scheme>://<trust-domain>/<path>

Trust domain is fundamental as it defines the scope

Scheme can be different, registered. Weighting using or

• How close to they want to be close to SPIFFE
• Do they want to be close to SPIFFE
• Could define more constraints

Path has relation to schme and trust domain

Trust domain

• Needs to define how this is related to issuer
• So far mostly an hostname but how do they want to have it related to
  a registered domain name

How much descriptive the WG wants to be on the nature and format of
identifier is a core question

Not all the use cases have been fleshed out yet, there is a backlog

• need more feedback on the list first
• then feedback on what might be missing

Deployment model:

• Are they important to them or just another group problem

Discussion

Flemming -- will the draft focus on just the WIMSE identifier or still
include other aspects of identity
-- adding clarity around the identifier but will still have aspects of
the larger identity use cases

Richard -- what is the identifier addressing?
-- the workload identifier is focused on identifying the workload as
defined in the spec

Ned -- draft mentions the domain can be tied to the X509 certificate?
where is the mapping?
-- still an open issue, trust domain is part of the identifier
-- in the X509 world the trust domain probably maps to CAs
--

Dean - trust domains defines the path?
-- maybe define isn't the correct word
-- trust domain defines the set of issuers and the associated namespace

-- trust domain will have to coordinate how those identifiers have
meaning within that domain

Dean -- how does the scheme relate to the path component
-- the scheme defines what the allowed path elements are
-- or have a scheme of wimse and the trust-domain component

Darin -- properties of identifiers as it relates to authorization?
-- concernans on the not strict definition of properties
-- concerns around the necessary parsing of paths?
-- does having it well defined make it easier?
-- important to define the properties of the identifier

Daniel -- if move to X509 world?
-- the full URI would go into a URI sand field

Evan -- concerns around overloading identifiers for authorization
especially in ABAC oriented implementation
-- keep the intent of the identifier simple
-- don't overload for detailed authorization purposes

David Broussard (from chat):
-- Agreed with Evan & Daryn
-- Maybe the way forward is to mention best practices around AuthZ

Flemming -- regarding use cases, delegation and impersonation are
important use cases to consider
-- Definition of workloads can have a lot of different meaning
(processes, etc.)
-- Want coverage of delegation and impersonation
-- need to be addressed early on

Token Delivery BCP - 20min (Hannes Tschofenig)

• https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/

Link to the draft is not correct in the slides - this is not about hpke

Title was adapted to reflect scope of work

RFC7523 is mostly focused on JWT Bearer method only

RFC does not define how to acquire the JWT but 3 patterns emerged:
Environement variable, file, local socket

Exchange the JWT (RFC7523) with an Authorization Server for an access
token

No mention of X.509 certification nor proof of posession

a two ways decision for the WG:

1. Keep scope narrow and go WGLC
2. Expand the scope
   • Other WG are talking about those already and are not referenced

Chair / Justin reminds that this document being called a BCP is still
into discussion. Which path to the WG wants to go:

• Listing options
• Being more opiniated about the guidance

Globally, large discussion on the nature of this document: is this a
BCP? should it be a BCP?

Vote:

• How many read it? : More than the writers for sure
• Scope to be widen? : 19/6 for yes + 5 no opinion
• Take it to the list.

Discussion

Flemming -- is the purpose to document real world deployments? or what
the WG is proposing should happen?
-- YES :-)
-- current representign what people are doing today, this is a
representation of the best current practice

Evan -- not familiar with "bearer" method? how the token is validated?
-- looking for the mechanics of how the JWT is validated by the
Authorization Server
-- needs more clarification around validation rules in the spec
-- focus on recommended best practice for the full processing of the
flow (obtaining an access token)

Brian -- words matter... concerned with use of "best"
-- should this document carry the term "best"
-- maybe just documenting the current practice -- focus on
informational

Mark -- would like to move away from bearer tokens to bound credentials

-- architecture team discussed confidential computing and how it maps
into this space
-- confidential containers are probably not "current practice"
-- bound credentials are used in many use cases today... would like the
workgroup to address bound credential solutions

Flemming -- agree with Brian, this doc is informational
-- focus is too narrow right now
-- value in documenting what people are doing today
-- need to expand the scope

Arndt -- would like to keep the scope narrow
-- would like to focus on what people are doing right now
-- describe the security properties well
-- how much do we need to focus on K8 and adoptions

Jeff -- recommend proposing best current practice at the beginning of
the effort
-- this recommendation came way to late for OAuth / OpenID Connect.
People implemented early not following best practice which has caused
issues

Service Security Design Team - 30 min (Yaron Sheffer)

• https://datatracker.ietf.org/doc/draft-sheffer-wimse-s2s-protocol/

Assuming an identity server and authorization decision needs to be done,
when Workload A talks to Workload B

• not covering any call-chain or flow context
• not addressing any cross-domain issues
• nto defining discovery of endpoints

• not OpenID Connect as some product express it

  • it might be called OIDC cause they are using ways to expose keys
    as OIDC does it

• Allows usage of other elements like Transactions Tokens and OAuth2
  bearer tokens, but do not force usage of one, the other, or none

Two solutions proposed

• transport level (mTLS)
• application level: DPoP or HTTP Message Signatures
  • the WG does not think providing both is a good thing.

WIT (WIMSE Identity Token):

• a little bit like a certificate

• is a JWS

  • asymetric signature
  • but it is NOT a bearer token

• binding to a key

DPOP inspired option / WIMSE Proof Token (WPT)

So two headers and two tokens:

1. The WIT
2. a proof of key token related to the WIT
   • Signature if the proof token has cnf pointing to WIT
   • have standard jti, exp
   • have hashes of other tokens that can be passed along the
     request: Access, Transaction, or other

HTTP Message Digest option

Out of the Box you get signature of the request and the response.

Mutual TLS option

So there is this third option, similar to SPIFFE

Vote

Call for adoption will be submitted to the list

Discussion

Hannes -- hashes for binding external tokens also being presented?
imposing too much vs to little guidance to developers?
-- aud is there to prevent replay to a different "target URI"
-- token hashes are all optional, but the text is written to say that if
an access token is present then the hash must be present. Effectively...
"conditionally optional"

Evan -- like the including of the audience claim
-- expiry can become difficult to manage in a async delivery mechanism
-- another option might be to use an iat claim to allow the reciever
to determine if the token is still valid
-- considerations for use of these tokens outside of the HTTP transport
context
-- take this conversation to the list

Kenneth -- doc mentions that tokens must be signed by a central identity
server? can this be relaxed?
-- allow for self-signed tokens with reference to some well defined
trust anchors?
-- workload signs it's own key and then points to some other service
that can validate that token
-- take this topic to the list as well

Ned Smith (chat): I think POP is different from certification. Don't
think they can be conflated using self-signed structures. certification
gives a name to a key by a trusted entity. POP proves the private
portion of the key is held.

Hannes -- was there any consideration for how tokens/signatures
propagate across call chains
-- the focus of this spec is just between two servers

Flemming -- great progress in a short time. Well done.

Token Exchange Design Team - 30 min (Dean Saxe/Yaroslav Rosomakho)

• https://datatracker.ietf.org/doc/draft-rosomakho-wimse-tokentranslation-reqs/

• https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-translation/

There are a large set of implementation of Token Exchange, lead by OAuth

This lead to a confusion that this is in relation to OAuth only, in fact
no WIMSE is a superset of Exchange type and patterns

WIMSE Identity Token can have different representations and this need
translation in between those types

John Kemp - I do not think "exchange" should be included in
"translation" - I think they are disjoint concepts. A token may be both
translated into another token, and also exchanged for that token (handed
in, and perhaps invalidated by the entity doing the exchange).

Ned Smith: Does token translation remove the signature over the token?
If so, how does the resulting token get resigned by the original issuer?

Dean Saxe: Not yet defined, Ned.

Token Type can have influence on flows and scopes

8 Token format translation characteristics

• Format pure
• Long lived for short live
• Cryptographic scheme changes (especially for PQE)
• Content enrichment, change

There are some security considerations to take care of to prevent abuse
and escalation

Translation might have 3 forms:

• tied to RFC8693
• Lossless
• Lossy
  • This need to be profiled

WG feedback is required on characteristics that need to be addressed

Vote

Who read? handful

Should the chairs ask for adoption for these documents?
No and No opinion ( 7 + 10 ) vs yes (4)

Discussion

John -- difference between token translation and token exchange?
-- in an exchange the original token could be invalidated in favor of
the new token
-- translation does not necessarily invalidate the original token
-- Dean: the concern makes sense... more discussion needed

Brian -- OAuth Token Exchange is not constrained to two token types
-- intent was that in the OAuth case, it can take in any token type and
return any other token type
-- meant to be wide open and an arbitrary exchange method
-- Dean: the term "translation" allows for loss of data
-- continue conversation on this mailing list

Evan -- the individual translation requirements make sense
-- would be very helpful to have some explicit examples
-- e.g. going from SPIFFE JWT to an AWS token
-- make the different requirements concrete

Yaron -- plus one for Evan's comments
-- recommend refer back to the charter as some of the concrete examples
can be included

Arndt -- is the translation service be within the trust domain? or cross
trust domains?
-- Dean: probably witin the trust domain, look at this in a similar way
to other token translation/exchange services work today
-- Yaroslav: also thinks about the service within the trust domain
-- what is the different between translation and issuance? could
attestation help here?
-- Dean: in some cases some workloads may only accept certain kinds of
tokens
-- more discussion needed

Jeff -- is there a need for the concept of byReference vs byValue?
-- is this another requirement
-- translate from a "clear" token to an opaque token for privacy reasons

Evan -- has a model where the translation service is external to the
trust domain
-- maybe this is an extension of the trust domain
-- deployment models/patterns are important

Authentication Levels for Workloads - 10 min (Ryan Hurst)

Looking at SP800-63-3
Needs to define the levels, should it be part of WIMSE

This would be new work and likely an expansion of the WIMSE charter

Vote

Discussion

Dean -- is informational RFC the correct level? or should we go for
something more prescriptive?
-- be as specific as possible and it needs to allow for a spectrum of
implementations
-- align directionally around the properties of the credentials or event
that occurred
-- properties of the credentials / process is

Jeff -- are you recommending this specific process? Should you not also
look into FAL?
-- the NIST slide is more just an example

John -- opposed to the wording of "level" is it implies one level is
better than another
-- agreed, the properties/implications of the different authentication
"levels" is important

Other Business - 5 min (chairs)

If you see any missing element, participate and create a Draft

thanks for the session by Orie
See you in Dublin