OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] Minutes from SSTC Call (Tuesday 22 November 2016) ---- RE: Proposed Agenda for SSTC Telecon (Tuesday 22 November 2016)

On 12/2/16, 5:53 AM, "Rainer Hoerbe" <rainer@hoerbe.at> wrote:

> Therefore I suggest to rename the extension to „requesting ad-hoc sets of attributes“.

Renaming the whole spec would mean getting new templates, etc. If it's really an issue, I would suggest using text in the intro to clarify what it's about.
> Actually entity categories (https://github.com/iay/entity-category) are a second method for signaling pre
>-defined sets of requested attributes. While still not an RFC, they can me used to signal bundles of requested
> attributes.

I think you could just finesse that. I mean, "local lists of services" (e.g. the Shibboleth filter policy mechanism) is also a mechanism, right? You could just say "Mechanisms for signaling pre-defined sets of requested attributes, such as use of SAML metadata in conjunction with the AttributeConsumingServiceIndex attribute..."

> The same collision as with requested attributes would apply. @Scott: is it technically possible to reference an
> IETF-draft in an OASIS spec?

Not a draft, at least not once this were to advance farther.

> re "SAML Metadata MAY be used to indicate support for
>     this protocol extension“. I doubt that this is useful unless it is mandatory, because
>     if an entity really needs this information, it has to poll it somewhere else to be complete.  

All metadata in the original standard is optional, so all discussions of it use language like that, there's no real option there.

-- Scott


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]