RE: [security-services] SAML Browser Profiles Metadata

[<Frederick.Hirsch@nokia.com>]

I have the following comments and questions on Draft 04 (25-Apr-03) 
of the SAML 1.1 Metadata for Web Browser SSO Profiles. 

[xxx] refers to line xxx in the document.

1) General question - should this specification include support for single logout and defederation as well?
If so, we may need to extend providerDescriptorType.

2) Should we summarize the differences from Liberty in an appendix?
(There are also some places where differences are not noted, e.g. 2.1 intro)

2). [100] The provider definitions seem to include the "SSO profile" as part of the definitions. 
This seems awkward. Perhaps [99]-[101] should be reworded as follows:
--
This Metadata for SAML 1.1 Web Browser SSO Profile specification uses the following (Liberty) terminology :
*	Identity Provider (IDP) - the source of metadata. (?)
*	Service Provider (SP) - the destination or consumer of metadata. (?)
--
I'm not sure I understand these definitions - I thought an IDP provided an authentication and identity mapping
service and an SP participated in federation. With regard to metadata, aren't both consumers of metadata as well
as members of a circle of trust that includes metadata agreements? Is there a special role in the context of
metadata? (otherwise I suggest we use Liberty glossary definitions)

3). It might clarify the apparent contradiction between [108] and section 2.1 regarding multiple providers to add the following before section 2.1 (after line [110]:
--
Multiple providerIDs may be used to identify a single provider. This allows multiple unique identifiers for the provider. This is supported in the metadata schema by using multiple SPDescriptors in a metadata description, each associated with a single providerID.
--
[Did I get this right? Question; I believe a service url is associated with a providerID, so what would be the motivation for multiple providerIDs? Is it to allow versioning of a service? ]

4)Perhaps defining cacheDuration in addition to validUntil in 2.1.3 would be useful given HTTP caching.

5)Would defining a general AdditionalMetaLocation (where to get additional information) also be useful?

6) Can Organization [194],  have an id attribute of type xsd:ID? 
(In general anything that might be signed should have an id attribute?)

7) [306] and [324] are inconsistent. s/AssertionConsumerServiceURL/AssertionConsumerURL/

8) 2.1.7.1 [325] since more than one AssertionConsumerURL is allowed, should an isDefault attribute be associated with one of them to allow a default to be defined for requests or is there a processing rule? (see Liberty)

9) Perhaps we should have both the providerID and the providerSuccinctID (SHA-1 hash of providerID) to avoid
confusion and relate the SAML SourceID to the providerSuccinctID?

10) Would it be useful to retain optional contactPerson elements?


regards, Frederick

Frederick Hirsch
Nokia Mobile Phones