OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: Re: [saml-dev] The Core specification is the only "mandatory" specification, the others are just helpful guidelines, right?

On 6/19/06, Costello, Roger L. <costello@mitre.org> wrote:
> Core
> Profiles
> Bindings
> Authentication Context
> Metadata

I would swap Bindings and Profiles in the above ordering.

> Question: the Core specification is the authoritative specification.  It
> defines the SAML XML vocabulary.  It defines what tags can be used in a SAML
> document, what is the meaning of each tag, and how applications should
> process each tag.  Correct?

Basically, yes.  (I would use the word "element", not "tag".)

> Question: the other four specifications are not required; they are intended
> to be used as "guidelines" and "helpful hints" of how the SAML XML
> vocabulary might be used in common situations.  For example, the Profiles
> specification describes 14 interaction patterns, but applications that use
> SAML don't have to use any of those 14 interaction patterns, correct?

Well, no, the above statements are too weak.  The SAML specs are not
"guidelines" or "helpful hints."  They are *specifications* that
define *standards* (from a reputable standards body) that deployers
can follow for the purposes of *interoperability*.

> And
> even if an application wants to, say, implement Web Browser SSO, it doesn't
> have to follow what's described in the Profile specification for Web Browser
> SSO.

If I were an architect or consultant, I would never advise a client
otherwise, would you?

> As long as the application uses the SAML vocabulary in a fashion
> consistent with the Core specification then it's okay.  Correct?

Depends on what you mean by "okay".  Either you comply with a SAML
profile or you don't.  If you don't, you don't interoperate with those
that do.  That's not "okay" in my book.

I think what you mean to say is that there are other profiles of SAML
apart from those published in the Profiles document.  Of course that
is true, but if a third-party profile comes along that competes with
one of those in the Profiles document, I'd choose the latter


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