Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-burl-03.txt

From: [email-masked]
Date: Mon, 26 Sep 2005 10:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: Message Submission BURL Extension
	Author(s)	: C. Newman
	Filename	: draft-ietf-lemonade-burl-03.txt
	Pages		: 13
	Date		: 2005-9-26
	
The submission profile of Simple Mail Transfer Protocol (SMTP)
   provides a standard way for an email client to submit a complete
   message for delivery.  This specification extends the submission
   profile by adding a new BURL command which can be used to fetch
   submission data from an Internet Message Access Protocol (IMAP)
   server.  This permits a mail client to inject content from an IMAP
   server into the SMTP infrastructure without downloading it to the
   client and uploading it back to the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-burl-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-burl-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Sep 2005 14:14:28 -0700

BURL revision 3 was published:

The most substantive IESG comment on BURL was from Sam Hartman:

----
Discuss [2005-08-31]:
The burl draft does not provide enough information and does not
require a mandatory to implement mechanism such that a submit server
from one vendor is guaranteed to be able to interoperate with an imap
server from another vendor.

Here are examples of missing information:

1) Mandatory to implement authentication mechanism for submit servers
to support when contacting imap servers.

2) How does the submit server log in?  Obvious answers include using
the submit credential with no authorization id or the submit
credential with the authorization ID of the user after submit+/user+.
I think the first option is probably preferable, although it may
involve some imap ickyness.
----

As a result I added the following two paragraphs to revision 03 of BURL:

----
   When the submit server connects to the IMAP server, it is acting as
   an IMAP client and thus is subject to the mandatory-to-implement IMAP
   capabilities in section 6.1.1 of RFC 3501 as well as the security
   considerations in section 11 of RFC 3501.  To guarantee
   interoperability between IMAP and submit servers from different
   vendors, the submit server MUST implement a configuration where it
   uses STARTTLS followed by SASL PLAIN [I-D.ietf-sasl-plain] to
   authenticate to the IMAP server with submit credentials.  The
   authentication id and password used MUST be configurable.  The string
   "submit" is suggested as a default value for the authentication id
   with no default for the password.  When resolving a URLAUTH IMAP URL,
   the authorization and authentication id are typically the same
   because the URL includes separate authorization.

   When resolving a regular IMAP URL and both the submit client and
   submit server's embedded IMAP client are using STARTTLS with SASL
   PLAIN (or the equivalent), the submit server SHOULD cache and replay
   the client's credentials.  If the submit server supports other SASL
   mechanisms, it MUST implement a configuration where the submit
   server's embedded IMAP client uses STARTTLS and SASL PLAIN with the
   submit server's authentication id and password and the submit
   client's authorization id.
----

Is this a sufficient response to the comment?

        - Chris

---

From: Chris Newman <[email-masked]>
Date: Wed, 28 Sep 2005 00:33:26 -0700

Sam Hartman wrote on 9/26/05 21:55 -0400:
>>>>>> "Chris" == Chris Newman <[email-masked]> writes:
>     Chris> the password.  When resolving a URLAUTH IMAP URL, the
>     Chris> authorization and authentication id are typically the same
>     Chris> because the URL includes separate authorization.
>
> Is this really true?  I would expect the authorization ID to be empty,
> not the same as the authentication ID.
>
> I'm also very uncomfortable saying the authorization ID should be the
> same as the authentication ID because they come from different
> namespaces in SASL.  In SASL, the authentication ID comes from a
> namespace defined by the mechanism while the authorization ID (when
> expressed over the wire) comes from a namespace defined either by the
> application protocol or by the server implementation depending on how
> much detail is specified in the application protocol.

I've never seen the namespace for authentication and authorization id differ in 
an email protocol, so to me there's no difference.  However, since the LDAP 
community seems to like the distinction, I'm fine with changing it to say empty.

> I'm also uncomfortable with the idea that we are recommending caching
> credentials used with the submit client for use with the IMAP server.
> I'm going to seek additional review on this point from the security
> community and see how comfortable others are with this proposal.

I can delete that sentence if necessary to get approval.  However, when 
implementing proxy authentication, the two options are credential forwarding or 
use of a proxy credential which can authorize as any user.  In the event the 
submit server is compromised, the former exposes no additional information 
beyond what the attacker could get anyway, while the latter gives the attacker 
unrestricted access.  Since PLAIN + TLS supports credential forwarding, I 
consider that the safer choice.

                - Chris

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Sep 2005 21:55:22 -0400

However I do agree with the general approach you are taking and
believe that these are the only issues I have.

--Sam

---

From: Mark Crispin <[email-masked]>
Date: Wed, 28 Sep 2005 08:31:56 -0700 (PDT)

On Wed, 28 Sep 2005, Chris Newman wrote:
> I've never seen the namespace for authentication and authorization id differ 
> in an email protocol, so to me there's no difference.  However, since the 
> LDAP community seems to like the distinction, I'm fine with changing it to 
> say empty.

Uh, let's talk about this a bit more.

To me, the authorization ID being empty is simply a convention of the 
protocol to indicate that the authorization ID is loaded from the 
authentication ID.  As Chris says, there is no difference in namespace 
between authentication and authorization IDs in email protocols.

Consider Kerberos (which is presumably an example of where the difference 
between mechanism and application namespace).  Either the IMAP server uses 
the entire name@realm principal as identifiers (both authentication and 
authorization), or it decides that such-as-such realm is permitted to have 
"name" extracted and used as identifiers (both authentication and 
authorization).

Either way, the authentication ID is then used for one of two things: 
either to confirm that authentication ID can acquire the desired 
authorization ID's credentials OR to load the authorization ID.  Once that 
is done, only the authorization ID matters from then on.

If the BURL document implies some other way of doing things (e.g., in a 
misguided attempt to match LDAP), this is going to confuse the hell out of 
those who follow existing practice and will lead to lots of needless 
arguments.

I don't see how this difference makes a difference, but it has the 
potential to waste a lot of time.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Sep 2005 13:38:03 -0400

>>  Is this really true?  I would expect the authorization ID to
    >> be empty, not the same as the authentication ID.
    >> 
    >> I'm also very uncomfortable saying the authorization ID should
    >> be the same as the authentication ID because they come from
    >> different namespaces in SASL.  In SASL, the authentication ID
    >> comes from a namespace defined by the mechanism while the
    >> authorization ID (when expressed over the wire) comes from a
    >> namespace defined either by the application protocol or by the
    >> server implementation depending on how much detail is specified
    >> in the application protocol.

    Chris> I've never seen the namespace for authentication and
    Chris> authorization id differ in an email protocol, 

This thinking is very inconsistent with thinking in the SASL working
group.  Please see section 2 of draft-ietf-sasl-rfc2222bis.

Conceptually I'd say that the authentication identity for SASL
external is implementation dependent.  Likely candidates include a
full certificate or the X.500 subject name from a certifacte.  Neither
of these identities is in the authorization ID namespace used by  IMAP.

The situation is similar for Kerberos.  The over-the-wire encoding of
the authentication ID is an ASN.1 DER encoding of a Kerberos principal
structure.  As represented within GSSAPI, the authentication identity
is a gss name, which is a combination of an OID and a buffer of
octets.  Again, definitely not the same namespace as authorization IDs
for IMAP.

Many SASL implementations do tend to normalize authentication IDs and
based on the origins of these implementations it is not surprising
their normalization works well for IMAP.

    Chris> so to me
    Chris> there's no difference.  

Section 2 of the new SASL base spec disagrees with you significantly.
I'm not asking you to reference that document so you could make an
argument based on 2222.  However I believe it is reasonable for the
IESG to ask for consistency between what is going on in lemonade and
SASL, particularly when it is easy to get.

    Chris> say empty.

    >> I'm also uncomfortable with the idea that we are recommending
    >> caching credentials used with the submit client for use with
    >> the IMAP server.  I'm going to seek additional review on this
    >> point from the security community and see how comfortable
    >> others are with this proposal.

    Chris> I can delete that sentence if necessary to get approval.
    Chris> However, when implementing proxy authentication, the two
    Chris> options are credential forwarding or use of a proxy
    Chris> credential which can authorize as any user.  In the event
    Chris> the submit server is compromised, the former exposes no
    Chris> additional information beyond what the attacker could get
    Chris> anyway, while the latter gives the attacker unrestricted
    Chris> access.  Since PLAIN + TLS supports credential forwarding,
    Chris> I consider that the safer choice.

I've talked to other security people.  People tend to agree that proxy
authentication with plain+tls is OK to standardize.  You need to
discuss the risks of using this feature in your security
considerations section.  Also, I believe you should say something like
"The cached credential SHOULD NOT be sent to the imap server unless it
is known to be in the same administrative domain as the submit
server."  I'm not sure that the normative advice needs to be quite
that strong so let me describe what I'm worried about in case you want
to work on the text.

An imap URL used with a submit server could potentially point to any
imap server.  It seems reasonable if both servers are in the same
administrative domain--particularly if they use the same backend
authentication database--to proxy the credentials.  But it would be
undesirable if a user is convinced to go submit a message based on
some imap URL in another organization to trick the submit server into
giving that imap server the credentials for the submit server..

The only significant risk I see to discuss in the security
considerations section is the possibility that credentials are given
to the wrong server..  I was also concerned about the risk that a
password could be cached for a long time, but I see you already
require the url be resolved before the command response is generated.

--Sam

---

From: Mark Crispin <[email-masked]>
Date: Wed, 28 Sep 2005 11:10:07 -0700 (PDT)

> group.  Please see section 2 of draft-ietf-sasl-rfc2222bis.

This is the first that I have ever heard of this, and I wrote one of the 
oldest implementations (Chris wrote the other) of SASL.

If the SASL Working Group intends to change the definition of SASL from 
under protocols that have used SASL for over a decade, they ought to send 
at least a polite note to the various communities for those protocols 
seeking their agreement.  Otherwise, you may hear howls of rage from 
people who thought that the SASL Working Group was merely clarifying and 
updating SASL, not changing it incompatibly.

Another possible interpretation is that no incompatible change is being 
made, and that this is merely a confusion over terminology.  If so, then 
we should be discussing how to resolve the confusion.

> of these identities is in the authorization ID namespace used by  IMAP.

An authentication identity that can not be transformed into an identity 
that is meaningful to IMAP is *NOT* something that IMAP can use.

Furthermore, the idea of the authorization identity being "empty" is 
meaningless to us.  Yes, it may be empty in the protocol, but to us that 
merely means "derive authorization identity from authentication identity."

> octets.  Again, definitely not the same namespace as authorization IDs

This is irrelevant; it is simply what is transmitted over the wire.

> their normalization works well for IMAP.

This isn't a "normalization".  This is a translation.

Kerberos does not know anything about IMAP identity namespace.  There is 
nothing in the Kerberos principal that contains what authorization 
identities can be used.  That is entirely done by the IMAP server.

In effect, there are three identities:
  1) the Kerberos principal, transmitted via SASL
  2) the authentication identity, which is derived from (1)
  3) the authorization identity, which is either:
     a) transmitted via SASL, and validated against (2)
     b) derived from (2) if SASL transmitted empty or doesn't transmit
        authorization identity.

Once this all happens, only (3) is of any further concern to the IMAP 
server.  IMAP does not allow you to change identity.

(3) can not be empty.  Everything depends upon it.

There is no difference between a transmitted authentication identity of 
"mrc" in one SASL mechanism and one of "[email-masked]" in Kerberos. 
Either way, (2) ends up as "mrc" (null transformation in one case, 
validation that "u.washington.edu" is a permitted realm in the other) and 
is subsequently used as the authentication identity.

There is no difference between transmitted an authorization identity of 
"mrc", and transmitting a blank authorization identity and having "mrc" be 
derived from the authentication identity; either way, (3) ends up as 
"mrc".

This same is true in any other SASL negotiation.  In many cases, the 
derivation of (2) from (1) is a null transformation.  Nevertheless, it is 
a step that is taken in all cases.

Any other way is madness.  You're in effect saying that every protocol has 
to maintain separate authentication identities based upon which SASL 
mechanism was used; and worse that this is what is used as the protocol's 
security model (since the transmitted authorization identity is blank).

> SASL, particularly when it is easy to get.

I hope very much that this is a terminology difference.  If this is a 
proposal for an incompatible change to SASL, you will hear howls of rage.

I think that we're confusing what goes on the wire with what happens 
within the protocol.  I hope that we can clarify this without declaring 
that one, or the other, is "broken" in some way.

Please tell me that this is the case, and that warfare isn't on the 
horizon.

-- Mark --

http://panda.com/mrc

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Sep 2005 14:57:01 -0400

I'm fairly sure there is no incompatible change to SASL.

The only potentially incompatible change is that 2222bis clearly
defines a meaning for an empty authorization ID transmitted over the
wire.  The SASL working group claims this is a clarification not a
change.

There is a significant model change about how authorization identities
and authentication identities are conceptualized.  When I was chair of
SASL, there was consensus behind significant parts of this model
although you would need to ask current chairs to make any consensus
calls.  That model significantly disagrees with how you describe
things but not in any ways that affect what goes over the wire.

It is my belief that the model proposed in SASL is consistent with
2222 but that it is significantly more clear.

--Sam

---

From: Chris Newman <[email-masked]>
Date: Wed, 28 Sep 2005 12:06:22 -0700

Mark Crispin wrote on 9/28/05 8:31 -0700:

> ...
> I don't see how this difference makes a difference, but it has the potential
> to waste a lot of time.

In an attempt to be more precise:

Each SASL mechanism may have a mechanism specific authentication id, and this 
may be encoded in some funky way when transmitted over the wire (e.g. Kerberos5 
ASN.1 or X.509).

Almost every implementation will have code to convert from the 
mechanism-specific authentication id with encoding to a mechanism-neutral 
string form of the authentication id.  This conversion process may be 
configurable (in the case of an X.509 certificate, typically the conversion 
involves parsing the certificate subject to derive a human-friendly id).  To 
implementers like you and me, Mark, this step is just implicit.  The SASL WG 
decided to make this an explicit part of the model.

When the authorization id is empty, a default value is chosen based on the 
mechanism-neutral string form of the authentication id.  For email protocols, 
the identity function is almost always used (although some canonicalization to 
allow both "uid" and "uid@default-domain" is typical).  For LDAP, the 
authorization id is typically a user-hostile LDAP DN, so in that case a mapping 
from user-friendly ID to user-hostile DN is typically necessary.

I'll try to come up with text that should make everyone happy.

                - Chris

---

From: Mark Crispin <[email-masked]>
Date: Wed, 28 Sep 2005 12:21:13 -0700 (PDT)

Chris (and Sam) -

I agree with Chris' representation of the issue, discussed below.  If this 
is acceptable to Sam as well, then we're all on the same page (as I had 
hoped) and just need the right wording to express it so that it's 
acceptable to everyone.

I just want to make certain that I'm not hit by some flamer years in the 
future for "doing SASL the wrong way" due to the emtpy authorization 
identity debate.

Thanks

On Wed, 28 Sep 2005, Chris Newman wrote:
> may be encoded in some funky way when transmitted over the wire (e.g. 
> Kerberos5 ASN.1 or X.509).
>
> the identity function is almost always used (although some canonicalization 
> to allow both "uid" and "uid@default-domain" is typical).  For LDAP, the 
> authorization id is typically a user-hostile LDAP DN, so in that case a 
> mapping from user-friendly ID to user-hostile DN is typically necessary.

-- Mark --

http://panda.com/mrc

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Sep 2005 16:03:22 -0400

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

I disagree with a few point in Chris's discussion.

    Mark> Thanks

    Mark> On Wed, 28 Sep 2005, Chris Newman wrote:
    >> Each SASL mechanism may have a mechanism specific
    >> authentication id, and this may be encoded in some funky way
    >> when transmitted over the wire (e.g. Kerberos5 ASN.1 or X.509).
    >> 
    >> mechanism-specific authentication id with encoding to a
    >> mechanism-neutral string form of the authentication id.  This
    >> conversion process may be configurable (in the case of an X.509
    >> certificate, typically the conversion involves parsing the
    >> certificate subject to derive a human-friendly id).  To
    >> implementers like you and me, Mark, this step is just implicit.

I agree up to this point.

    >> The SASL WG decided to make this an explicit part of the model.

I disagree with this claim.  The SASL working group decided to stop
what they standardize at what goes over the wire.  Your implementation
can convert everything in to mechanism-neutral authentication
identities, it can only support one mechanism, it can do whatever so
long as it actually works.

It is my understanding that the SASL working group has no normative
text on this issue.

    >> 
    >> When the authorization id is empty, a default value is chosen
    >> 

I agree with this sentence fragment.  IN addition, the authorization
ID that is chosen needs to be useful to the application.

    >> based on the mechanism-neutral string form of the
    >> authentication id.  For email protocols, the identity function
    >> is almost always used (although some canonicalization to allow
    >> both "uid" and "uid@default-domain" is typical).  For LDAP, the
    >> authorization id is typically a user-hostile LDAP DN, so in
    >> that case a mapping from user-friendly ID to user-hostile DN is
    >> typically necessary.

I agree this is best current practice for implementation.  The SASL
working group does not want to standardize this practice.  Instead
they want to standardize that if you send an empty authorization ID,
something reasonable will happen on the server.  If you send an
authorization ID, it better be in the right form for the application
at hand.

--Sam

---

From: Mark Crispin <[email-masked]>
Date: Wed, 28 Sep 2005 16:27:35 -0700 (PDT)

> It is my understanding that the SASL working group has no normative

OK, I think the problem may be that we have a different boundary in email. 
In particular, the authorization (not authentication!) identity defines a 
default namespace in IMAP in addition to access control.

I can understand that SASL may have wanted to steer away from the Scylla 
of being too IMAP-oriented (as early SASL undoubtably was), but there is 
also the Charybdis of being too LDAP-oriented and denying that in some 
protocols there is a relationship.

> authorization ID, it better be in the right form for the application

I agree.

Nevertheless, in the context of email protocols, we have standard 
semantics for authorization identity over and above what SASL chooses to 
standardize.  Since BURL, URLAUTH, etc. are part of email protocols, and 
use the identity semantics of email protocols, we can't say that it is 
wrong for these documents to refer to these semantics.

I think that the solution that we are groping towards is something to the 
effect of re-stating these semantics as being over-and-above SASL's 
semantics, as opposed to being inherited from SASL.

-- Mark --

http://panda.com/mrc

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Sep 2005 19:32:12 -0400

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> OK, I think the problem may be that we have a different
    Mark> boundary in email. In particular, the authorization (not
    Mark> authentication!) identity defines a default namespace in
    Mark> IMAP in addition to access control.

Yes, I understand this.  I don't understand how this is at all
inconsistent with anything I've said or problematic.

SASL lets you do this.

Do you have a problem saying that submit should send an empty
authorization ID over the wire to imap?  If so, please clearly explain
it because I don't see it at all?

Or is your problem that by the time it gets to the imap
implementation, then the authorization ID will have either been
transmitted or derived and by that point it must be an authorization
ID that IMAP understands and can give you a namespace?  If so, it
sounds like your problem with my statement is simply that I was being
sloppy and said authorization ID not transmitted authorization ID.  If
not, I'm confused completely.

--Sam

---

From: Mark Crispin <[email-masked]>
Date: Wed, 28 Sep 2005 16:54:41 -0700 (PDT)

> it because I don't see it at all?

I don't see how it matters what is sent over the wire in the case where 
the authentication identity and the authorization identity are the same.

However, I worry about a statement that says that "submit should send an 
empty authorization identity over the wire" because that seems to imply 
that it is not permitted to send a non-empty authorization identity.

In the case of Chris' text:
   [...] The
   authentication id and password used MUST be configurable.  The string
   "submit" is suggested as a default value for the authentication id
   with no default for the password.  When resolving a URLAUTH IMAP URL,
   the authorization and authentication id are typically the same
   because the URL includes separate authorization.
the context is important.  I read it as discussing the "effective" 
authentication and authorization identities as interpeted by email 
protocols, as opposed to the strings sent over the wire by SASL.

I think -- I am not sure that this has been discussed -- that if I 
send "mrc" as an authentication identity and "submit" as an authorization 
identity (assuming that "mrc" has the privilege to do this), then for the 
purposes of URLAUTH as used by BURL I am a submit server.

Perhaps the text in BURL should say something like:
   [...] The authorization id (and password if SASL PLAIN is used)
   used MUST be configurable.  The string "submit" is suggested as a
   default value for the authorization id with no default for the
   password.  When resolving a URLAUTH IMAP URL, the authorization
   and authentication id are typically the same because the URL
   includes separate authorization; in this case, "submit" is sent
   over the wire as the authentication id with an empty authorization
   id.

> sloppy and said authorization ID not transmitted authorization ID.

I think that we're all guilty of being sloppy, and this conversation is 
valuable since it forces us to clean up our sloppy messes.  We have plenty 
of unhappy lessons from not being as rigorous in the past.

There is clearly a difference between what is sent on the wire, and what 
is understood by IMAP, and since we've been confusing each other we need 
to express this more clealry.

-- Mark --

http://panda.com/mrc

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Sep 2005 16:41:24 +0100

> to support when contacting imap servers.

Sam, this is already described in IMAP RFC 3501. A submission server 
would just act as a regular IMAP client.

>   authenticate to the IMAP server with submit credentials.

I object to duplicating any information already mentioned in RFC 3501.
A direct reference to RFC 3501 would suffice.

>   The

Same as above. The RFC describing Submission (don't remember # from the 
top of my head) should already contain a mandatory to implement 
authentication mechanism.

> Is this a sufficient response to the comment?

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Sep 2005 12:51:01 -0400

I'm afraid that I'm going to have to insist on text similar to that
Chris proposes adding to the draft.  I don't think an RFC 3501
reference is sufficient.

I think there are enough additional issues that have surfaced in this
discussion that it is clear to me that e are going beyond RFC 3501 in
what we say.  I believe that is necessary and I believe that there is
no way to do so without duplication of 3501 text.

---

From: Chris Newman <[email-masked]>
Date: Fri, 30 Sep 2005 14:12:43 -0700

Alexey,

I agree with Sam on this point.  While those of us familiar with the RFCs know 
the issue is addressed sufficiently, people implementing for the first time 
won't know to chase down the references unless we tell them.

Furthermore, the text about authentication/authorization id covers information 
that can be derived from present specs if one fully understands them, but isn't 
actually written explicitly anywhere.  That's not particularly nice to 
implementers and it was right for Sam to call me on that mistake.

There's a balance between redundancy (which can get out-of-sync) and complexity 
of reference (which can trip up implementers) when writing specifications. 
Given the importance of secure interoperability, I'd prefer to err on the side 
of redundancy in this case.

                - Chris