[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]