For lossy translations, what is the proper path forward?

[deansaxe]

As discussed on the call on September 24, 2024 (Notes, we need to determine the mechanisms used to define lossy translations. In the initial ID we preferred the mechanism of profiling for any lossy translations. Profiling will require a mechanism to define the profile for each pair of tokens profiled in both directions (e.g. Token Type A to Token Type B, and the inverse B to A).

This leads to a number of outstanding questions:

1. How are profiles documented? Is this an RFC track document or are there other mechanisms for defining the profiles?
2. If the documentation is an RFC track document, can we develop a template to assist authors in writing profiles to speed the development of profiles for token translation?
3. Are we able to create buckets of translation types that can apply broadly across mutliple different token pairs in order to simplify the process of profiling? In other words, are there generic profiles that can be established to work across multiple token types?
4. How do we prioritize authoring profiles? Are there common use cases that exist today that could be developed as exemplars?
5. If the answer is not profiles, what other options do we have?

[identitymonk]

as discussed in #26 (comment) the profile should be formalized as opiniated guidance on how to set which value for which parameter of Oauth2 token Exchange for which translations, including additional information that could guide or ease the process of translation.

[deansaxe]

Based on the discussion and presentation at IETF 121, we are planning on authoring profiles for exchanges and translations. Additionally we'll add text to the document to indicate that this should not limit implementations from using other existing mechanisms (e.g. OAuth token exchange) when they meet their specific use cases. We're not trying to reinvent any wheels that already exist...