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] SAML Browser Profiles Metadata


Fredrick -
Your definition below is harmonious with the definitions in SAML binding
doc. I will incorporate your definition in draft 05, with the following
modification to remain consistent with SAML Binding doc:

The SAML 1.1 Metadata specification adopts Liberty’s terminology for
providers  as follows:
§	Identity Provider (IDP) means the source of a an authentication context.
The source performs initial user authentication.
§	Service Provider (SP) means the destination that provides services and
requires an authentication context.

Again, the words source and destination are italicized to indicate the fact
that we have borrowed them from the bindings doc.

Will this work for you?

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 12:27 PM
> To: jmoreh@sigaba.com; security-services@lists.oasis-open.org
> Subject: RE: [security-services] SAML Browser Profiles Metadata
>
>
> 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
> > >
> >
>


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