Return-Path: 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: Tue, 23 Feb 2010 22:51:10 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" 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 Return-Path: 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: Tue, 23 Feb 2010 22:36:34 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" 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 Return-Path: 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: Tue, 23 Feb 2010 16:52:29 +0100 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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. Return-Path: 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: Tue, 23 Feb 2010 13:32:46 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" 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 Return-Path: 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: Tue, 23 Feb 2010 08:37:15 +0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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.