[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bindings] w.r.t. "two types of binding"
Jeff,
I broadly agree with your suggestions here
and with the proposed text changes. I think the diagrams
can also be usefully added to some part of the bindings
document. Maybe in keeping with the core assertions documents
we can start moving towards an "examples" document and a
normative "bindings" document.
(1) I am comfortable with your characterization of "protocol
binding" and the proposed use of the term "protocol binding" within
the bindings doc.
(2) I am not quite so convinced about the term "service binding".
I find its usage not very helpful in that often we are referring to
adding assertions to objects belonging to some
kind of protocol or framework (HTTP, MIME, SOAP). In this case, I am
not sure where the service piece is. Presumably, there is an
application (Foo in Figure A) which is, in some sense, the service
to which assertions have been bound. But the assertions appear
within the protocol elements and the design issues center
around adding and securing SAML assertions into the protocol.
The term "SAML Profile for XXXX" or where XXXX is one of
HTTP, MIME, or SOAP has a better sound to me (text following
suggestion 2). But I have to say that I am puzzled by its use
in the current context. The standard meaning of profile is:
"a representation of something in outline;"
OR
"an outline seen or represented in sharp relief"
(Merriam-Webster: http://www.m-w.com/cgi-bin/dictionary)
How does that correspond to the notion of calling out detailed rules
for adding SAML assertions to some protocol or framework? Does
the word have a specialized meaning in security or computer science?
- prateek
>>-----Original Message-----
>>From: Jeff Hodges [mailto:jhodges@oblix.com]
>>Sent: Wednesday, May 09, 2001 8:39 PM
>>To: oasis sstc
>>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_specific
>>ation_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
>>
>>------------------------------------------------------------------
>>To unsubscribe from this elist send a message with the single word
>>"unsubscribe" in the body to:
>>security-services-request@lists.oasis-open.org
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC