RE: [security-services] SAML Browser Profiles Metadata

[<Frederick.Hirsch@nokia.com>]

Jahan

Thank you very much for the clarifications.

Regarding the IDP and SP definitions at [99]-[101], would this be useful wording?
---
This Metadata for SAML 1.1 Web Browser SSO Profile specification defines the following terms :

Identity Provider (IDP) - where authentication is performed, the source of an authentication context
Service Provider (SP) - where a service is provided and the destination where an authentication context may be required. 
---

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Jahan Moreh [mailto:jmoreh@sigaba.com]
> Sent: Monday, April 28, 2003 3:14 PM
> To: Hirsch Frederick (NMP/Boston);
> security-services@lists.oasis-open.org
> Subject: RE: [security-services] SAML Browser Profiles Metadata
> 
> 
> 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
> >
>