[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] new work - saml metadata extensions for trust information
On 2020-08-21 15:28, Cantor, Scott wrote: > On 8/21/20, 9:21 AM, "security-services@lists.oasis-open.org on behalf of Leif Johansson" <security-services@lists.oasis-open.org on behalf of leifj@sunet.se> wrote: > >> Looking at the information model I think we might need its not clear that it is just an attribute. > > Generally speaking though... > > - AttributeValue is an open content model > - anything that's not a simple-ish content model is likely to get botched or ignored anyway > - if it isn't simple, at least existing code bases that aren't lazy already support open content in AttributeValue > Yes and no. In this case its mainly large discovery services and fedops that need to implement and those can afford (and are interested in) the complexity. For instance I suspect InCommon might want to be able to point at SA and tell an SP "push this button and we'll decorate your SP metadata in such a way that only InCommon IdPs that profile to "sirtifi AL2" are presented as valid choices. It is true that anything can be represented as an AV... and I'll scratch my head about that some more but I sspectu you will just move the complexity into the A and V parts in such a way that the implementation comes out worse in the end... > I'm not making a blanket statement, just speaking generally that I tend toward trying to reuse the extension then defining new ones, simply to save time and to leverage existing configuration machinery. > A very good point. This might be clearer if I presented the concrete proposal... I am due to talk it through internally at seamlessaccess first but I will drop an outline here after that. Cheers Leif
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]