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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

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


Subject: RE: Bindings Con-Call Monday at 12Noon..


Minutes from Bindings Con-Call Monday, January 29, 12PM
-------------------------------------------------------

In Attendance:

Zahid Ahmed
Chris Ferris
Carlisle Adams
Jeff Hodges
Prateek Mishra

-----------

General agreement that the following are within scope
of bindings:

(1) Service Bindings
Mapping request/response protocols for Auth, Az and 
other security services into a specific messaging 
protocol such as SOAP/XP. Should call out all relevant
headers, encoding descriptions etc. in full detail.

(2) Application Binding
Includes recommendations on adding assertions to various
types of frameworks/transports. Should include:

(a) Web Browser Client (notice, this is a client
rather than a protocol)
(b) HTTP 
(c) MIME
(d) SMTP (related to (c)?)
(e) ebXML
(f) SOAP/XP
(g) BEEP

[Zahid, Chris, others]
It would be a good idea to call out a general construction
which could then be applied to specific protocols. This
would also serve as an example of how to integrate
security assertions with other protocols. This would also
highlight the security considerations that need to be
taken into account.

[Prateek, Zahid]
The web browser binding is kind of weird, it may not
fit with all the rest.

[General Discussion]
MIME is different from SOAP/XP, ebXML, BEEP; it is more like
a packaging framework

We are providing bindings at many different levels:
transport (HTTP), packaging (MIME), SOAP/XP (application
level). How do they play together? 

Each is appropriate in different contexts and has
different properties; for example,
the HTTP binding will have a point-to-point flavor, other
bindings will be transport independent etc.

[Jeff, Chris]
Concern that we are attempting to specify "normative" bindings
for protocols that are being worked on by other groups. Only 
ebXML, for example, can define a normative binding to security
assertions for ebXML. Maybe we need to scope our recommendation in 
an appropriate fashion? Should we be only providing examples?

[Prateek]
We do need some basic interoperability coming out of this work.
Our bindings need to be fully and formally specified even if
they are not considered normative for protocols with ongoing
activity.Some protocols are legacy protocols (HTTP,MIME)
and it is not
likely that there will be groups coming forward to consider
adding security assertions.
  
[Jeff]
Recommend use of a profile notion so that other groups can define
bindings as and when needed. We would provide guidelines or
definitions to aid them in doing so. We should follow previous
work such as SASL and others in this direction. There should be
some formal means of registering a binding.

[Chris,General]
Bindings work has very broad impact on the overall
work, including the sub-groups on use-cases and requirements, 
security considerations and core assertion model. We need to 
produce a document soon so we can have an impact on these 
groups.

[Zahid]
We need to consider the case where there are multiple
hops across protocols. E.g., an OBI step followed by
an ebXML step. How can security assertions travel with
the business process in this scenario?

Plan of Action
--------------
Jeff and Prateek to produce strawman document
by Friday, Feb 2.

Next Conference Call at Monday, 12noon, Feb 5,
to discuss document and next steps.

Jeff will generate text on Profile notion, review
Shiboleth literature.

Prateek will review AuthXML draft for relevant material
and put together document working with Jeff.

Zahid will provide material on multi-hop, multi-protocol
use-case.
  


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


Powered by eList eXpress LLC