To: [email-masked]
Date: Tue, 23 Feb 2010 22:51:10 -0000

Josh wrote:
> > The AssertionIdRef is basically just consumed by the relying party,=20
> > there aren't any rules in the spec for processing it or=20
> decorating it.
>=20
> Is there any harm in processing or decorating it such that we=20
> can obtain the kinds of semantics we've been discussing?

Reading SAML2Core section 2.3, would it be cleaner to use
AssertionURIRef instead, defining some namespace for this purpose?

Thinking aloud, might there also be some advantage in using the SAML URI
Binding rather than the Assertion Request Profile? The SAML URI Binding
is somewhat more lightweight.

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

Date: Tue, 23 Feb 2010 22:36:34 -0000
To: [email-masked]
Scott wrote:
> Josh Howlett wrote on 2010-02-18:
> > That makes a lot of sense. If you recall, the original=20
> approach was to=20
> > avoid authentication (which would imply a turtle issue) of the=20
> > call-back responder by attempting to match a hash claimed in the=20
> > artifact to the SAML message that it resolves. I believe we can=20
> > achieve a semantically equivalent effect by incorporating the same=20
> > hash in the AssertionIdRef value.
>=20
> The AssertionIdRef is basically just consumed by the relying=20
> party, there aren't any rules in the spec for processing it=20
> or decorating it.

Is there any harm in processing or decorating it such that we can obtain
the kinds of semantics we've been discussing?

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

Date: Tue, 23 Feb 2010 16:52:29 +0100
To: [email-masked]
Josh Howlett wrote:
> Alan wrote:
>> No. The RADEXT WG has specifically rejected any attempt to
>> increase the RADIUS MTU.
>
> What was the reason(s) given?

It would involve changes to the base spec, and could have unforeseen
side effects.

Alan DeKok.

Date: Tue, 23 Feb 2010 13:32:46 -0000
To: [email-masked]
Alan wrote:
> Josh Howlett wrote:
> > Sam wrote:
> >> First, I think the right technical approach is to ignore the RADIUS

> >> MTU issue.
> >=20
> > Would this be acceptable to IETF?=20
>=20
> No. The RADEXT WG has specifically rejected any attempt to=20
> increase the RADIUS MTU.

What was the reason(s) given?

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

Date: Tue, 23 Feb 2010 08:37:15 +0000
To: [email-masked]
Josh Howlett wrote:
> Sam wrote:
>> First, I think the right technical approach is to ignore the
>> RADIUS MTU issue.
>
> Would this be acceptable to IETF?

No. The RADEXT WG has specifically rejected any attempt to increase
the RADIUS MTU.

> Ot are you talking about the implementation?

A number of implementations are more "forgiving" about MTU.

Alan DeKok.