[Wimse] Re: Token Exchange and Translation Protocol

[Dean Saxe <[e-mail]>]

 Thank you all for the feedback.

I’m about to start a week of well deserved time out of the office with my
family.  Can I ask that those of you who have provided feedback on this doc
and/or the use cases doc authored by Yaroslav place your feedback in issues
and/or pull requests on the GitHub repos?

https://github.com/yaroslavros/wimse-tokentranslation-requirements

https://github.com/deansaxe/wimse-token-exchange-and-translation

When I return from being OOO I will set up a time for a regular meeting to
discuss these docs to see if we can make forward progress based on the
feedback.

Thank you,

-dhs

--
Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
Principal Engineer
Office of the CTO
Beyond Identity
[e-mail]




On Aug 12, 2024 at 1:33:02 PM, John Kemp <[e-mail]> wrote:

> I also support A, and related to Joe's comments below, I think we need
> to develop a deeper understanding of what token "translation" means,
> within the specific areas that Flemming pointed to in
> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html and
> also with particular regard to what is already in RFC8693.
>
> In my opinion, there are three overlapping concepts:
>
> 1. Token (initial) issuance -- in my mind, this token is issued in
> response to a set of primary identity claims being validated enough to
> "authenticate" the maker of those claims. In particular, token issuance
> is part of the SSO dance in response to a (human) user authentication
> event where the user is pretty explicitly delegating an application to
> operate on the user's behalf.
>
> 2. Token exchange -- a token is offered to a "security token service"
> and the token is a set of identity claims that are self-contained within
> the token but can be authenticated cryptographically within the context
> of that session. The original token is exchanged for a (one or more) new
> token(s), which may have different semantics than that of the original.
>
> 3. Token translation -- a token is provided, and the original semantics
> of that token are maintained in the production of a new token (or
> something) usable in a different context. We could describe these
> contexts as token translation "profiles".
>
> In the case of SPIFFE <-> "OAuth" we're pretty explicitly moving between
> a world where the root of identity is non-human, to one where the root
> of identity is (or started as) primarily human (and vice-versa). We may
> or may not need to maintain the human context (authorization of a human
> delegating to an application -- workload in/out of the context of a
> logged-in SSO session). In particular, I am mindful of "as a SPIFFE user
> with more than 10k workloads, I’d like to access OAuth protected
> resources without having to manage 10k OAuth Clients" (from the
> use-cases doc linked above).
>
> There are, of course, humans involved in workloads. The human that runs
> an application which calls a workload to run some query across some
> nodes, and authorizes it to run even while the human is logged out, say.
> Or the sysadmin/devops human that bootstraps an orchestration framework
> that offers nodes upon which workloads may run.
>
> Cheers,
>
> - johnk
>
> John Kemp
> Independent Security Architect
> e: [e-mail]
> t: +1.413.645.4169
>
> On 8/8/24 6:11 PM, Joseph Salowey wrote:
>
> I support A - continue to work on this document to develop it for
>
> working group adoption.  While the document needs a fair amount of work,
>
> I don't see anything that really hinders it from becoming something that
>
> we could adopt.
>
> What I would like to see in this document:
>
> 1. I would like to see the more concrete use cases and examples fleshed
>
> out more.  Maybe not all of them need to go into the document, but I
>
> think we will need these going forward.
>
> 2. Do we think that all the use cases will need to use a new token
>
> translation endpoint?  I'm not sure, but I really would like to
>
> understand the functionality and characteristics of the new endpoint.
>
> Also it seems token exchange would work for some of the use cases, would
>
> the use of existing token exchange procedures be described in this
>
> document as well?
>
> 3. I like that there already are some security considerations in the
>
> document, but I'd like to see a bit more fleshed out before adoption,
>
> but it does not need to be exhaustive at this point.
>
>
> Thanks,
>
>
> Joe
>
>
> On Wed, Jul 31, 2024 at 2:04 PM Flemming Andreasen (fandreas)
>
> <fandreas=[e-mail]
>
> <mailto:[e-mail]>> wrote:
>
>
>     __
>
>     Hi Dean
>
>
>     I think we are largely on the same page here. Wrt. the use cases
>
>     I-D, I assume you are referring to
>
>     https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html
>
>     <https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html>
> ? If so, that draft expired in February, and I'm not clear on what the
> intent of it is going forward. Regardless, when you look at the use cases
> described in there, I don't see anything specifically talking about token
> exchange/translation. I think I generally understand the notion of token
> exchange based on RFC 8693, however I'm less clear on token translation as
> defined in the draft. The AWS-to-SPIFFE scenario described in the draft
> makes sense, and I am asking for more such examples to help guide the
> specific translations we shold be focusing on (profiles). From a
> documentation point of view, I like the more descriptive style of some of
> the use cases, but I also recognize the value of the user story approach
> taken in the use-cases draft above - a combination of the two would be
> ideal from my point of view.
>
>
>     Cheers
>
>
>     -- Flemming
>
>
>
>     On 7/31/24 14:47, Dean Saxe wrote:
>
> >     Flemming,
>
> >
>
> >     Thank you again for the feedback.
>
> >
>
> >
>
> >     For IETF 120 the most important output (IMHO) was to frame up the
>
> >     problem space and an approach to solving for the use cases we
>
> >     identified.  The doc is rough and at a high level because we
>
> >     really needed feedback to inform the next steps - are we
>
> >     approaching this problem from the right perspective?  Are we
>
> >     missing something in the existing RFCs?
>
> >
>
> >     I agree that there’s more work to be done on the use cases draft
>
> >     to inform this document.
>
> >
>
> >     Additional commentary/questions inline below.
>
> >
>
> >     -dhs
>
> >     --
>
> >     Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
>
> >     Principal Engineer, Office of the CTO
>
> >     Beyond Identity
>
> >     [e-mail] <mailto:[e-mail]>
>
> >
>
> >
>
> >
>
> >
>
> >     On Jul 30, 2024 at 6:16:23 PM, Flemming Andreasen (fandreas)
>
> >     <fandreas=[e-mail]
>
> >     <mailto:[e-mail]>> wrote:
>
> >>     We have a charter item corresponding to this document and I don't
>
> >>     see any other candidate documents at this time, so I vote for A.
>
> >>
>
> >>     The document is pretty rough though and mostly introduces some of
>
> >>     the problems to consider. Additionally, the document would
>
> >>     benefit from the following:
>
> >>     - More work on the requirements to feed into this document (per
>
> >>     separate e-mail thread on requirements)
>
> >>     - A set of representative use case scenarios to illustrate what
>
> >>     we are after. This is especially important for the "token
>
> >>     translation" scenarios.
>
> >
>
> >     How is this different from the use cases described in the use
>
> >     cases I-D?  Are these more concrete examples or something entirely
>
> >     different?
>
> >
>
> >>     - Clarity on whether we aim to use (/profile) RFC 8693 for "token
>
> >>     translation" or whether that is only for "token exchange"
>
> >
>
> >     I have an action item to follow up with Brian Campbell on this as
>
> >     discussed in the WG last week.
>
> >
>
> >
>
> >>     - Clarity on which token formats we want to be able to
>
> >>     translate/exchange. While the document notes that these will be
>
> >>     provided as "translation profiles", we shold understand the
>
> >>     target ones early on, and develop at least some of them in
>
> >>     parallel with the basic translation/exchange protocol.
>
> >
>
> >     I am supportive of developing the profiles side-by-side with this
>
> >     ID.  I thought I had said that in the meeting, but if I did not,
>
> >     that was my intent.  My thought process was to enable profiles to
>
> >     be developed on a separate track to allow the WG to deliver RFC
>
> >     candidates more quickly without allowing one profile to bog down
>
> >     the work on the larger token translation doc.
>
> >
>
> >     If you have suggested token translations to focus on in the near
>
> >     term, please let me know.
>
> >
>
> >
>
> >>
>
> >>     Cheers
>
> >>
>
> >>     -- Flemming
>
> >>
>
> >>
>
> >>     On 7/29/24 08:25, Justin Richer wrote:
>
> >>>     Following discussion in Vancouver, the chairs would like to
>
> >>>     begin discussion on what the next steps should be for the Token
>
> >>>     Exchange and Translation Protocol document [1], an output of the
>
> >>>     Token Exchange Design Team. This is not a call for adoption as
>
> >>>     there was a clear indication in the room that the document was
>
> >>>     not yet ready for this stage.
>
> >>>
>
> >>>     Please reply to the list to indicate that:
>
> >>>
>
> >>>     A: You believe this document should be developed into a state
>
> >>>     that the WG can adopt it. (Please discuss what you believe would
>
> >>>     be required changes for this. Please keep in mind that a call
>
> >>>     for adoption is a starting point for a document, not a finished
>
> >>>     document.)
>
> >>>
>
> >>>     B: You believe this document should NOT be developed further by
>
> >>>     the WG. (Please indicate why if possible)
>
> >>>
>
> >>>     C: You need more information before making this decision.
>
> >>>     (Please indicate what information you’d need)
>
> >>>
>
> >>>     D: You don’t give a flying rat about this document (i.e., this
>
> >>>     is not a topic you care strongly about)
>
> >>>
>
> >>>
>
> >>>     Please reply to the list by August 12th, 2024.
>
> >>>
>
> >>>     — Justin and Pieter
>
> >>>
>
> >>>     [1]
>
> >>>
> https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-translation/
> <
> https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-translation/
> >
>
> >>>
>
> >>>
>
> >>>
>
> >>
>
> >>     --
>
> >>     Wimse mailing list -- [e-mail] <mailto:[e-mail]>
>
> >>     To unsubscribe send an email to [e-mail]
>
> >>     <mailto:[e-mail]>
>
>
>     --
>
>     Wimse mailing list -- [e-mail] <mailto:[e-mail]>
>
>     To unsubscribe send an email to [e-mail]
>
>     <mailto:[e-mail]>
>
>
>
>