Vectors of Trust was meant to be used in place of things like AuthenticationContextReference (acr) and its kin, so this is a fair assessment.
It does still require a shared understanding of what a given vector means by processing it in the context of its trust mark. — Justin > On Dec 23, 2019, at 2:13 PM, Benjamin Kaduk <[email protected]> wrote: > > On Tue, Dec 17, 2019 at 09:12:26PM +0000, Richard Backman, Annabelle wrote: >>> That's a pretty strong statement :) >> >> One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is >> not used at all, just that it is not universal and comes with real, >> practical tradeoffs that may not be appropriate for all use cases. >> Consequently, we should not design fundamental specs that mandate its >> adoption. >> >> >>> …knowledge of that level isn't necessary. >> >> Either the RS and AS have a shared understanding of that level, or the RS is >> trusting the AS to decide what “AuthenticatedClient” means, and set it >> accordingly. The latter requires that the RS only supports ASes that have a >> shared (or substantially similar) understanding of what that level is, which >> is unlikely outside of a closed system. In that case, there isn’t a lot of >> value in providing a standard claim, as the closed system could just as >> easily define a proprietary one. > > Talk of the different potential levels of authentication calls to mind RFC > 8485's "Vectors of Trust" idiom, though, IIUC, it would require some > adaptation to be useful here. > > -Ben > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
