Produits Entr'ouvert » Authentic 2

Parce que c’est les données effectives de l’usager (claims) dont le partage est consenti par l’usager qui nous importent dans notre modèle d’autorisation, pas la couche d’abstraction (scopes) à laquelle le fournisseur d’identité et le fournisseur de service ont recours pour se mettre d’accord entre eux.

Cela impliquerait, à chaque /authorization/, de recalculer pour les scopes demandés sur les claims correspondantes ont déjà été autorisées par l’usager.

Il y a aussi, dans la discussion dont émane ce ticket (#100992), l’idée qu’on pourrait revoir un peu la façon dont les claims sont présentées à l’usager d’une part, et modifiables dans le BO d’autre part :

[…] un claim a un nom visible, on doit envoyer ce que ce nom dit, sinon c'est un autre claim […] Donc ici j'ajouterai un display_name à OIDCClaim, initialisé à attribute.name si on peut déterminer un attribut, sinon claim.name et ces champs sont non modifiables après la création du claim.

(Les cas où on ne peut pas déterminer directement un attribut seraient par exemple celle où la valeur du claim est une expression de gabarit.)