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


First some broad brush questions:

 

(A)

 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.

 

(B)

It seems to me to be useful if the IDPDescriptor, SPDescriptor, AttributeService and AttributeConsumingService (could we rename this to AttributeConsumer?)

and  were to include:

(a)     Which Name Identifier formats are supported?

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

(c)     # of assertions expected or returned

(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.

 

The idea here is that most scenarios involve IdPs, SPs, AttributeServices, AttributeConsumers used in relatively restricted ways. This information needs to be exposed as early as possible so that misunderstandings between consumers and producers can be eliminated easily. Absence of this information indicates that any schema-valid assertion or response may be served up by a producer; similarly consumers can consume any schema-valid assertion or response.

 

And now for some nits:

 

(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.

 

(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?

 

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

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.

 

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.

 

(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?

 

(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.

 



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