[Wimse] Re: Token Exchange and Translation Protocol

[John Kemp <[e-mail]>]

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]>
> 
>