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] Groups - draft-saml-requesting-attributes-extension-v1.0.pdf uploaded

Hi Scott,

Thank you for your input!

In fact, I would prefer the option that you suggested, to have a req-attr:RequestedAttributes wrapper over a list of md:RequestAttribute, but one of the comments previously received made me think this is against the SAML specification:

„SAML extension elements MUST be namespace-qualified in a non-SAML-defined namespace“ as of sstc-saml-core-errata-2.0-wd-07 line 1566.

So I assumed this applies not only for the top level elements included in extensions, but also for their children elements. Is this not the case?

This is how an Extensions sample would look like, following your suggestion:

<md:RequestedAttribute isRequired="true" Name="LastName"/>
<md:RequestedAttribute isRequired="true" Name="FirstName"/>
<md:RequestedAttribute Name="Email"/>
<md:RequestedAttribute Name="Role">
<saml:AttributeValue>End User</saml:AttributeValue>
Could you please confirm if this would actually be compliant? If yes, I will modify my proposal accordingly. 

On Thu, Oct 20, 2016 at 10:42 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> The proposal was previously submitted and presented by my colleague Mert
> Aybat, and the current document version aims to integrate all the comments
> received at that time. The older email threads related to this topic can be
> found here: http://markmail.org/message/bjqll753qnbp4kkr &
> http://markmail.org/message/zzbopgn37nvisoj3 .
> Looking forward to your feedback.

This draft seems to be defining a new element that essentally duplicates the existing md:RequestedAttribute element, and that's a bad idea, due to confusion if nothing else. Instead, I would simply define a new wrapper element, perhaps <req-attr:RequestedAttributes> and define it as a sequence of zero or more <md:RequestedAttribute> elements.

That gives us insulation within the Extensions element but reuses the schema we already have.

The other comment is that the Conformance section is a bit off the track, but I can do a draft with appropriate wording once this is in a real OASIS template. It's really just boilerplate and I know what it needs to say. Basically the trick to the wording is saying "An SP is conformant to this profile if it has the ability to..." and so forth.

-- Scott

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Connectis accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

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