Hi Josh,
Hi Hans,
Hannes wrote:
Melinda wrote:
and that there are
some non-trivial advantages to carrying authorizations in-band.
Namely...
I don't wish to speak for Melinda, but this is a view
shared by many
within my own community.
I have a long list of applications, collected from within this
community, with which they would like to use SAML-based
authorisation;
Interesting. Any interest to share it with us?
I'm in the process of trying to flesh it out at the moment, in
a collaboration with some of the communities concerned, so
that we can articulate some concrete use-cases. At the moment
the list covers pretty much everything that is presently used
in an Inter-Institutional context (AFS, SSH, VNC, RDP, SIP,
SMTP, NEA, ...).
Looking forward to see more about it.
and it seems to me that the ability for application
protocols to share
a common mechanism for expressing authorisation would mitigate or
perhaps even avoid the need to make application-specific
authorisation
extensions.
My experience: authorization is often related to the specific
application domain.
I agree insofar as 'authorisation' is often an exercise in
making statements using semantics that are specific to
application domains, but I don't believe it follows that the
syntactical and transport elements (that support the semantic
expression) also need to be specific to the application domain.
Furthermore, working on SIP SAML I noticed the problems when you go
down to specific solutions scenarios.
Can you expand?
Look at http://tools.ietf.org/html/draft-ietf-sip-saml-05.
We started with a specific problem in mind, described in RFC 4484.
There are obviously different design approaches one can take and SIP is a
complex protocol and hence there are not always point-to-point interactions
making it somewhat difficult to provide similar functionality at a lower
layer. With specific details about the actual authorization statements we
also had a hard time. We published a few specifications (all expired in the
meanwhile) that discussed more or less complex attributes. Examples:
http://tools.ietf.org/html/draft-schubert-sipping-saml-cpc-02
http://tools.ietf.org/html/draft-schwartz-sipping-spit-saml-01
http://tools.ietf.org/html/draft-jennings-sipping-pay-06
Since you mentioned SIP as one of the usage scenarios in the paragraph above
you might have had other use cases in mind.
For many of the protocols and usage scenarios it may not even be so obvious
what SAML can actually give you (not even touching the subject of where to
put the SAML assertions).
My fear about SAML in TLS was a history like the following one:
* Hmmm. SAML becomes popular. We should put it in every protocol.
* There isn't an extension for TLS defined yet. Let's do it.
* Now, let's search for the problems it could solve.
(The fact that SAML-based Web SSO uses SAML that is bound to the
application-layer is, I believe, only an artifact of a
requirement to
avoid modifying contemporary Web browsers and I don't think
it is an
approach that would necessarily be desirable for the general case.)
... a reasonable transition plan, in my view.
Sure.
The reason for the success of these IdM solutions, particularly
OpenID.
(Well - OpenID has been a flop in my opinion. It has its uses,
but not very interesting ones. But I digress...)
There are different camps, without doubt. Just to point you to one other
opinion -- Jeff Schiller's webblog I recently discovered:
http://qyv.net/jisblog/2007/05/08/identity-on-the-internet/
Binding authorisation to TLS, as suggested by this document, is one
approach that would satisfy the 'common mechanism'
requirement indicated previously.
Looking forward to see your solutions.
I have no answers; I'm still trying to figure out what the
questions are :-/
I was referring to the usage scenarios you are working on.
Btw, I am not suggesting that folks shouldn't spend their time on usage of
authorization in TLS. I am more looking for some of the background of the
work as it often not too obvious from the pure specification. Your pointer
to http://kerberos.org/software/kerbweb.pdf is certainly helpful for a
number of folks -- I have learned it already from Jeff.
Ciao
Hannes
josh.
JANET(UK) is a trading name of The JNT Association, a company
limited by guarantee which is registered in England under No.
2881024 and whose Registered Office is at Lumen House, Library
Avenue, Harwell Science and Innovation Campus, Didcot,
Oxfordshire. OX11 0SG
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf