Re: Bindings Con-Call Monday (29-Jan) at 12Noon.. (minutes)

[Jeff Hodges <jhodges@oblix.com>]

Thanks for sending the minutes out Prateek. I think we can use them as a basis
to see if we can flesh these thoughts out further. I think I'll have more
musings on the stuff below, but will have to do it tomorrow (err, later today). 

thanks,

JeffH
-----

"Mishra, Prateek" wrote:
> 
[snippage]
> 
> 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


I realize we did some hand-waving and made the above distinction on the
concall, but I'm not sure what others were thinking it really constituted. With
just the language above, it seems to be that (1) and (2) are talking about the
same things. 


> 
> [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.

I tend to agree. If what is actually meant by "web browser binding" is that
authn & authz state needs to be maintained for a requester's
off-the-shelf-web-browser-based session, then it seems to me that this ~is~
protocol level stuff in the sense that one would specify how it wrked in terms
of RFC 2109 (and RFC 2616). 



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

Specifically [rfc2045 et al], it's a "message format" standard.  


> 
> 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
                       ^
                      BEEP (and some others I'd have to look up)


> 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.
>