[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