Notetakers:
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:
Kudos to the Design team for work on Token Exchange and Service to
Service security (round of applause)
Status update
Need to deep dive more on Workload Identity, will have a session today
on this
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
Path has relation to schme and trust domain
Trust domain
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
Deployment model:
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
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:
Chair / Justin reminds that this document being called a BCP is still
into discussion. Which path to the WG wants to go:
Globally, large discussion on the nature of this document: is this a
BCP? should it be a BCP?
Vote:
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
Assuming an identity server and authorization decision needs to be done,
when Workload A talks to Workload B
not OpenID Connect as some product express 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
WIT (WIMSE Identity Token):
is a JWS
binding to a key
So two headers and two tokens:
cnf pointing to WITjti, expOut of the Box you get signature of the request and the response.
So there is this third option, similar to SPIFFE
Call for adoption will be submitted to the list
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.
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
There are some security considerations to take care of to prevent abuse
and escalation
Translation might have 3 forms:
WG feedback is required on characteristics that need to be addressed
Who read? handful
Should the chairs ask for adoption for these documents?
No and No opinion ( 7 + 10 ) vs yes (4)
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
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
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
If you see any missing element, participate and create a Draft
thanks for the session by Orie
See you in Dublin