[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bindings] w.r.t. "two types of binding"
We had a discussion about some subtle-but-important terminology, w.r.t. "types
of binding", on the bindings concall last week. I committed to write up an
explanation/analysis of my thoughts. This is that writeup.
The executive summary is that it provides concrete definitions and analysis of
the use in practice of the terms "protocol binding", "service binding", and
"profile".
This is thus largely a contribution to the bindings section, but we may find
use for the illustrations and descriptions in other portions of the SAML spec,
e.g. an "examples" section.
JeffH
----------------------------------------------------------------------------
Background:
We had a security-bindings concall last Thur 3-May-2001. Prateek had updated
his set of slides from F2F#2 and we discussed it. The updated slides are cached
here..
Subject: Bindings presentation for discussion
http://lists.oasis-open.org/archives/security-bindings/200105/msg00002.html
presentation-bindings-may1.ppt
http://lists.oasis-open.org/archives/security-bindings/200105/ppt00000.ppt
We had a discussion about slide#3, which says..
> Two Types of Binding
>
> Protocol Binding: formats for combining and communicating assertions
> (with payload) from one system entity to another. May involve one or
> more intermediate parties.
>
> Service Binding: Interaction between SAML service provider and consumer
> over standard messaging protocols (SOAP, BEEP)
It seems to me that the above is effectively a rewording of the "Scope"
subsection (line 740) of the Bindings section (line 704) of..
http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-spec-00.PDF
The pertinent text of the "Scope" subsection begins with line 743 and is..
> The high-level goal of the Bindings subcommittee is to specify how..
>
> (1) security assertions are embedded in or combined with other
> objects (e.g. files of various types), communicated from site
> to site over various protocols, and subsequently scrutinized, and,
>
> (2) security services defined with SAML as message exchanges
> (e.g., the Authz protocol utilized between PDP and PEP in
> [Use Case 2, Straw2]) are mapped into one or more standard
> messaging protocols such as SOAP/XP and BEEP.
>
> (1) and (2) MUST be specified in sufficient detail to yield
> interoperability when independently implemented.
Note that (1) seems to more-or-less map to the "protocol binding" item in
slide#3, and (2) to "service binding".
Claim:
I feel we need to clarify whatever of the above text ends up appearing in the
SAML spec because I think it is somewhat vague and hard to understand, and
because I feel the rough definitions of "protocol binding" and "service
binding" are essentially reversed. I feel it is worthwhile spending some time
getting such subtle-but-important stuff right because it increases the odds
that readers will understand these concepts and thus help increase the odds
that independent implementors will be able to create interoperable
implementations.
Here is suggested new wording for the "Scope" subsection of
draft-sstc-saml-spec-00 beginning with line 743 (with an accompanying deletion
of lines 741 & 742)..
=-=-=-= suggestion 1 =-=-=-=
The scope of this Bindings section is the specification of how..
(1) SAML Request/Response messages are mapped onto underlying concrete
communication protocols. An instance of such a mapping is termed
a "protocol binding". This section specifies SAML protocol bindings
onto SOAP/XP, HTTP, ebXML, BEEP. Note that specifying protocol
bindings onto the foregoing protocols includes specifying the
packaging of SAML Request/Response Protocol messages using the
so-called HTTP "MIME-like" facilities (appendix 19.4 of [RFC2616]).
(2) SAML Core Assertions may be combined directly with other data objects,
generated by various systems and applications.
For example: files of various types, PDUs of communication protocols.
This includes specifying the packaging of SAML Core Assertions
using MIME [RFC2045] and so-called HTTP "MIME-like" facilities
(appendix 19.4 of [RFC2616]).
=-=-=-= suggestion 1 =-=-=-=
Accordingly, the "Deliverables" subsection (lines 751-784) will need revision
(note that in the completed spec the "deliverables" subsection ought to
essentially disappear).
Also, this means that slide#3 of presentation-bindings-may1.ppt should say
something like..
=-=-=-= suggestion 2 =-=-=-=
Two Types of Binding
Protocol Binding: SAML Request/Response Protocol messages are
mapped onto underlying communication protocols. (SOAP, BEEP)
Service Binding[*]: formats for combining assertions
with other data objects. These objects may be communicated
between various system entities. This might involve intermediate
parties.
=-=-=-= suggestion 2 =-=-=-=
[*] although I feel it is arguable that we should use the term "profile" for
the second "type of binding"; e.g. "a profile of SAML". see the discussion in
the "rationale" section below, under "Things to note in Fig. A".
Below's my rationale for the above suggestions.
Rationale:
I performed a moderately extensive search (thru W3C and IETF docs & selected
mailing list archives, and the web in general) for the terms "protocol binding"
and "service binding".
The term "protocol binding" is in widespread usage and well-defined in
practice, in senses largely mapping to that in suggestions 1 & 2. This is
notably the case in these documents..
SOAP: Simple Object Access Protocol
http://msdn.microsoft.com/xml/general/soapspec.asp
XML Protocol (XMLP) Requirements
http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/
ebXML Message Service Specification V0.99
http://www.ebxml.org/specdrafts/ebxml_message_service_specification_v0_99.pdf
The term "service binding" is relatively little used and thus not yet
well-defined in practice. For example, I searched my archives of > 100 IETF,
W3C, Oasis, etc lists for the two terms. I got ~ 130 hits for "protocol
binding" and 9 for "service binding". The latter were in the context of OPES
("Open Pluggable Edge Service") and ebXML (which actually doesn't use the term
"service binding" in it's present specs, but does have a "ServiceBinding"
element defined in the Collaboration-Protocol Profile and Agreement
Specification). These two efforts use the term roughly similarly -- it refers
to a high-level combination of runtime contextual information, e.g. who to
communicate with, how, where, and in what format.
Interestingly enough I note that the WSDL spec..
Web Services Description Language (WSDL) 1.1
http://msdn.microsoft.com/xml/general/wsdl.asp
..that a "service" is defined as a high-level artifact that is built up from a
collection of bindings to concrete protocols, data format specifications, and
network addresses. As such, it seems fairly congruent with the role of ebXML's
ServiceBinding element.
Below are some diagrams I'll use to try to further clairfy my thoughts (and my
understanding of a fairly concrete example of SAML usage (read: feedback
appreciated)).
First is Fig. A, a stripped-down illustration of a SAML-based deployment of
some application called "Foo". It is stripped-down in the sense that
interactions with SAML system entities other than a PEP and a PDP are not
shown.
=-=-=-=-=-=-= Fig. A =-=-=-=-=-=-=
System Entity Y
+-----------------+ +-------------------+
| | "Bar" protocol | |
| a component | requests & | another component |
| of "Foo" app +-----------------------+ of "Foo" app. |
| | responses | |
| (uses "Bar" | | | [resources] |
| protocol to | (over some protocol; | |
| request and/or | MAY contain SAML |-------------------|
| manipulate | assertions, but | PEP |
| resources | NOT SAML messages) | (SAML-speaking) |
| managed by | (See Fig. C) +-----+-------------+
| other "Foo" | |
| app components)| |
| | |
+-----------------+ |<--------+
System Entity X | |
| SAML asssertions +
| SAML messages (over
| a communication
| protocol, e.g.
| SOAP/XP, BEEP, HTTP)
|
| (See Fig. B)
|
|
+------+--------+
| |
| PDP |
|(SAML-speaking)|
| |
+---------------+
System Entity Z
"A stripped-down illustration of a SAML-based deployment of some
application called 'Foo'"
=-=-=-=-=-=-= Fig. A =-=-=-=-=-=-=
Things to note in Fig. A.:
* The PEP <--> PDP communication uses "SAML assertions + SAML messages" carried
over some underlying concrete communication protocol (see Fig. B below). This
is an operational example of a particular *protocol binding* between SAML and
the underlying communication protocol.
* The interactions between the "Foo" application components occurring over the
"Bar" protocol might contain SAML Assertions (e.g. Authentication assertions),
but DO NOT include SAML Messages.
Overall in Fig. A, Foo is making use of SAML in some way, whether or not SAML
assertions are being communicated over the "Bar" protocol between Foo
components. There's at least two terms used in practice to describe this
relationship between Foo and SAML. An emerging one seems to be "service
binding" (cf. WSDL and ebXML).
The other one is "profile". "Profile" is explicitly used to describe just such
relationships (especially for the case where the "Bar" protocol carries SAML
assertions). For example, when protocol designers make use of SASL in their
design, it is termed a "profile" of SASL (see
http://www.ietf.org/rfc/rfc2222.txt, section 4). Indeed, PKIX
(http://www.ietf.org/rfc/rfc2459.txt, Abstract) explicitly "...profiles the
X.509 v3 certificate and X.509 v2 CRL...". Also, when one specifies a protocol
using BEEP, one is specifying a "BEEP profile" (see
http://www.ietf.org/rfc/rfc3080.txt, Introduction).
Fig B illustrates the on-the-wire view of the PEP <--> PDP communication of Fig
A.
=-=-=-=-=-=-= Fig. B =-=-=-=-=-=-=
+----------------------------+
| |
| SAML Request/Response |
| messages |
| |
| +-------------------+ |
| | SAML assertion(s) | |
| | | |
| +-------------------+ |
| |
+----------------------------+
| |
| Communication protocols |
| (SOAP/XP,BEEP,HTTP, etc.) |
| |
+----------------------------+
| TCP |
+----------------------------+
| IP |
+----------------------------+
"SAML Protocol Binding to underlying concrete
communication protocol"
=-=-=-=-=-=-= Fig. B =-=-=-=-=-=-=
Fig C schmatically illustrates SAML assertions might be combined with other
data objects (please do not read it as implying *anything* about the
"enveloped/enveloping" question though ;) and *perhaps* communicated between
various system entities.
=-=-=-=-=-=-= Fig. C =-=-=-=-=-=-=
+----------------------------+
| |
| Some "document", chunk of |
| data, and/or some app | <----- a data object that may never
| protocol's PDU | leave a system entity, or may
| | be schlepped between various
| +-------------------+ | system entities by various
| | SAML assertion(s) | | means -- store-and-forward
| | | | (e.g. SMTP), sneaker-net,
| +-------------------+ | file transfer (e.g. SMB, NFS,
| | AFS, FTP), and communication
+----------------------------+ protocols.
. .
. .
. .
. Various protocols (NFS, .
. SOAP/XP,BEEP,HTTP,SMTP, .
. NIKE, ASICS, etc.)
+............................+
. TCP, carpet, parquet, etc. .
+............................+
. IP, subflooring, etc. .
+............................+
"SAML assertions associated with arbitrary data objects
which may or may not be schlepped between system entities
in arbitrary fashions"
=-=-=-=-=-=-= Fig. C =-=-=-=-=-=-=
---
end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC