RE: [security-services] SAML Browser Profiles Metadata

["Jahan Moreh" <jmoreh@sigaba.com>]

Fredrick -
Thanks for your review. I have incorporated some of your suggestions and
will publish draft 05 later today. Below are my answers to your questions.

Thanks,
Jahan

----------------
Jahan Moreh
Chief Security Architect
310.286.3070

> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: Monday, April 28, 2003 11:21 AM
> To: jmoreh@sigaba.com; security-services@lists.oasis-open.org
> Subject: RE: [security-services] SAML Browser Profiles Metadata
>
>
> 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.
I do not believe it should. The reason is that SAML does not have such
concepts. I intentionally omitted these Liberty-specified protocols from
SAML in order to avoid having "orphaned" metadata elements (i.e., metadata
elements with no SAML context).

> 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)
This could be very useful. I didn't have time to do it but can certainly
take a stab at in the 2.0 time frame.

> 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. (?)
Within SAML web browser sso profiles "source" and "destination" have
specific meanings. Basically, source is the place where a user goes (or is
redirected to go) for authentication and destination is the place where the
user gets "service". That is why I have italicized the words source,
destination, and provider to indicate the contextual meaning of each within
their respective specifications.

> *	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.
This is certainly true in Liberty. Please remember that SAML does not have
the notion of Identity Mapping or Federation (yet). So, using exact Liberty
definitions would not work.

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)
Both are consumers. In terms of Circle of Trust, again, SAML does not have
such a notion (at least not explicitly). In any case, if there is any doubt
that both can be consumers of Metadata, I will add clarification text in the
next draft as follows: "Note that both the IDP and the SP are usually
producers and consumers of metadata"

> 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.
Excellent suggestions. I was looking for a succinct way of clarifying this
apparent contradiction and you have provided nice text.
> [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? ]
The motivation is for a provider that supports both profiles
(Browser/Artifact and Browser/POST). For example, the
AssertionConsumerServiceURLs for a service provider that supports both
profiles may be different. At this time, the only way to specify this
(without introducing a new element or attribute that distinguishes between
the two profiles) is to have two SPDescriptors.

> 4)Perhaps defining cacheDuration in addition to validUntil in
> 2.1.3 would be useful given HTTP caching.
I thought about this but chose not to specify it because the spec does not
mention the protocol for exchanging the metadata. Again, specifying this
attribute makes it rather "orphaned" as there is no context in which we can
provide a useful example.

> 5)Would defining a general AdditionalMetaLocation (where to get
> additional information) also be useful?
In general I think these (Liberty stuff) are all useful. I used the
following rules in making the decision regarding adopting/not adopting:
1. Make it simple.
2. Do not add any elements/attributes to Liberty metadata spec. unless it is
absolutely necessary (I do realize that AdditionalMetadataLocation is a
liberty element).
3. Use the "Extension" element as the catch-basin for many of the "optional"
stuff and leave them unspecified.

> 6) Can Organization [194],  have an id attribute of type xsd:ID?
> (In general anything that might be signed should have an id attribute?)
I adopted this straight from Liberty. In the Liberty spec. this element does
not have an ID attribute. In any case, the Organization element is not
meaningful unless it is encapsulated in a providerDescriptor (which does
have an ID and can be signed).

> 7) [306] and [324] are inconsistent.
> s/AssertionConsumerServiceURL/AssertionConsumerURL/
Thanks. Corrected in draft 05.

> 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)
Very good point. Upon reflection (an based on the original non-liberty draft
of SAML metadata), I would change the schema such that exactly one
AssertionConsumerServiceURL MUST be specified.

> 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?
Well, that's what I thought I did without explicitly introducing the notion
of a providerSuccinctID. The reason I did not do it is because the term
providerSuccinctID is Liberty-specific.

> 10) Would it be useful to retain optional contactPerson elements?
It would, except that it introduces a new liberty namespaces (personal
information profile) to SAML and I did not think it was worth the trouble.

>
> regards, Frederick
Thank you for excellent suggestions and feedback.
> Frederick Hirsch
> Nokia Mobile Phones
>