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] Comments on sstc-saml-schema-metadata-2.0.xsd


>  I assume that the md:KeyDescriptor element describes the 
> certificates used by a Role and whether or not encryption is 
> used. In other words, trust roots and optional use of 
> encryption is captured by this element.

Yes, they would indicate keys for signing and encryption, or in some
deployments, key names that would be referenced somewhere else.

> (a)     Which Name Identifier formats are supported?

Something I didn't think through but probably makes sense.

> (b)     Whether attributes are to be returned, and, if so, 
> what are the relevant <AttributeDesignator>'s?

Could be.

> (c)     # of assertions expected or returned

Does this matter?

> (d)     listing of all other optional elements that the IdP 
> will generate, with their arities (if non-zero).
> (e)     Listing of all other optional elements within an 
> assertion that an SP will require, together with arities.

Such as? I'm assuming for example that an SP that also is an attribute
consumer would not need to say "I want these attributes" and then also
duplicate that information in the SP descriptor. What other content are you
thinking about? I assumed for example that issues like confirmation methods
were best handled other than statically, but we could revisit this.

> (1) Why is element <PDPDescriptor> included? I had thought that we
> had agreed that we would not include any more functionality in this space
> and that AuthZRequest/AuthZResponse processing would be frozen at the
> level of SAML 1.1 functionality.

I assumed that meant we needed to document it in metadata. It's not a major
piece in any case.

> (2) Instead of the ProviderID attribute, could each entity descriptor
> could include an issuer element instead? Is there any difference 
> between the issuer element found in an assertion and an EntityDesciptor's
> ProviderID attribute?

Not in the typical case in which metadata would be used, no. Could certainly
consider this.

> (3) What is the function of the <DefaultEndpoint> element 
> included within the <RoleDescriptorType>? 

Looking at ID-FF, one finds they have a SOAPEndpoint element, and the way
endpoints are expressed, there is no way to expose a second SOAP endpoint
(that is, multiple protocols must be exposed by that one endpoint).

My goal was to permit differentiation, but not require duplication of
information in the common case where many different protocols/services
shared the SOAP endpoint. Perhaps too complex and we don't care about space.

> For example, if an IDP[Descriptor] supports only the FORM 
> post protocol, does it have a <DefaultEndpoint> ?
> I guess this element is optional, so perhaps that answers my 
> own question. 

My last tweak generalized this to a default endpoint per binding. So if my
IdP supports SOAP and HTTP/Redirect, I could have a default for each. This
isn't enforcable with XSD except using key constraints.

> Is the fact all of the elements within a <RoleDescriptor> 
> element are optional a good thing? Perhaps an XML guru could 
> advise us on this point.

It's fairly tough to mix support for defaulting and overriding things and
end up with an XSD-imposed structure, but dumping the defaults eliminates
much of this ambiguity, I admit.

> (4) We haven't yet discussed the issue of including the 
> <NameIdentifierMappingService> with SAML 2.0. 
> Is there a use-case for it within SAML 2.0?

Yes, I believe it is necessary if you have federated identifiers. For one
thing, it directly serves the goal of allowing services to make use of SAML
attribute authorities without requiring federations between every pair.

I consider it part of work item W-2 and just hadn't proposed the text yet.
Note that I pushed for it in ID-FF precisely to support interop with SAML.

> (5) I am puzzled by the optionality of the Location and 
> ResponseLocation attribute for EndpointType. Is it really acceptable that 
> this information can be omitted from an Endpoint? It would seem to me that
> these are the single most important pieces of data required to access an
> endpoint. 

Has to do with the defaulting issue. Idea was that for a given binding you
could advertise support for a protocol but default the endpoint location.
This isn't expressible with XSD.

Removing the defaults simply creates duplication of information, but is
obviously easier to grok.

-- Scott



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