Return-Path: <IME-Version: 1.>
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Wed, 24 Feb 2010 13:57:06 -0000
MIME-Version: 1.0
Message-Id: <200305122255.h4CMt1U02501@example.com>
To: abfab@ietf.org
Content-Type: text/plain; charset="us-ascii"
> > Reading SAML2Core section 2.3, would it be cleaner to use=20
> > AssertionURIRef instead, defining some namespace for this purpose?
>=20
> I don't think there's much difference, really.

I was thinking about what this might mean for the implementer of a SAML
issuer. Decorating the assertion ID with these semantics surely implies
that the code that constructs the assertion needs to be aware of binding
that will be used to obtain it, or else it must decorate all assertions
using this method; both seem rather intrusive. If we use a URI
reference, I don't think we need to touch that part of the SAML issuer.
=20
> > Thinking aloud, might there also be some advantage in using=20
> the SAML=20
> > URI Binding rather than the Assertion Request Profile? The SAML URI=20
> > Binding is somewhat more lightweight.
>=20
> It's more lightweight at the cost of limiting the security=20
> features to HTTP, rather than SOAP.

Ok, I think that's probably a feature in this context. I can't see what
value SOAP adds.

> If I understand what you're thinking about, I think all that=20
> is moot here because you're looking for different places to=20
> put the authentication of the peers and trying to exchange a=20
> hash along with the data you want to pass because the channel=20
> is already supposed to be authenticated.

That's what I was thinking.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG