Re: [Gen-art] Gen-ART review of draft-johansson-loa-registry-04

Leif Johansson <> Sun, 01 April 2012 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 521DF21F88B0; Sun, 1 Apr 2012 14:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zorBGEThFOqr; Sun, 1 Apr 2012 14:59:33 -0700 (PDT)
Received: from ( [IPv6:2001:948:4:1::66]) by (Postfix) with ESMTP id D1B8021F88AF; Sun, 1 Apr 2012 14:59:32 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q31LxJup022834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2012 23:59:22 +0200 (CEST)
Message-ID: <>
Date: Sun, 01 Apr 2012 23:59:19 +0200
From: Leif Johansson <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 01 Apr 2012 15:17:27 -0700
Subject: Re: [Gen-art] Gen-ART review of draft-johansson-loa-registry-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Apr 2012 21:59:34 -0000

Hash: SHA1

On 04/01/2012 10:57 PM, wrote:
> I am the assigned Gen-ART reviewer for this draft. For background
> on Gen-ART, please see the FAQ at 
> <>.
> Please resolve these comments along with any other Last Call
> comments you may receive.
> Document: draft-johansson-loa-registry-04 Reviewer: David L. Black 
> Review Date: April 1, 2012 IETF LC End Date: April 3, 2012 IESG
> Telechat date: April 12, 2012
> This draft establishes an IETF registry of SAML Level of Assurance
> (LoA) profiles; it's short and clear, although it does not contain
> any initial content for the registry - presumably that will be
> supplied after the registry is created via the expert review
> registration mechanism established by this draft.
> Summary: This draft is on the right track but has open issues,
> described in the review.
> Major issues: (1) My major open issue concerns the last paragraph
> in the Introduction:
> Although the registry will contain URIs that reference SAML 
> Authentication Context Profiles other protocols MAY use such URIs
> to represent levels of assurance definitions without relying on
> their SAML XML definitions.  Use of the registry by protocols other
> than SAML or OpenID Connect is encouraged.
> While this is good in principle, and one presumes that each
> registration of sets of profiles from an existing protocol will be
> self-consistent, this text also encourages other (e.g., new)
> protocols to draw upon this registry without providing any
> guidance.  I'm concerned that it's probably possible to make a
> serious mess in a new protocol by using an LoA or two from
> multiple sets of registered LoAs without paying attention to
> whether the resulting collection of LoAs is consistent or coherent
> (or even sensible) for use in a single protocol.  This concern is
> reinforced by the guidance to expert reviewers in Section 4.1,
> which effectively conveys a desire to get all of the reasonable LoA
> profiles registered here, regardless of source or consistency with
> other registered LoA profiles.
> I'd like to see some guidance to protocol designers and others for
> how to appropriately select multiple LoA profiles from this
> registry in a fashion that results in a consistent and (hopefully)
> usable collection.  For example, it may be a good idea to use (or
> start with) a set of related profiles already in use by an existing
> protocol in preference to mixing/matching individual profiles from
> multiple existing protocols.  At some level, this is common sense
> advice that the presence of profiles in this registry does not
> obviate the need to apply good design judgment, but that does
> deserve to be stated.


The type of consistency you look for is extremely difficult to ascertain
and often rely on mapping the underlying policies. However I do see your
point. How about this:

"Protocol designers who want to reference this registry should be aware
that registered LoAs may depend on assumptions that do not carry over
to a new protocol."

> Minor issues: (2)
> (1) This draft is intended to be an informational RFC, but it uses 
> RFC 2119 keywords.  That's only a good idea in exceptional
> circumstances. I suggest removing section 1.1 and replacing upper
> case MUST/SHOULD/MAY with their lower case versions or reworded
> explanations of rationale.  Most of the uses of RFC 2119 keywords
> are not protocol requirements, but requirements on IANA,
> registrants, and users of the registry for which RFC 2119 keywords 
> are not appropriate, e.g., see RFC 2119 section 6:
> Imperatives of the type defined in this memo must be used with
> care and sparingly.  In particular, they MUST only be used where it
> is actually required for interoperation or to limit behavior which
> has potential for causing harm (e.g., limiting retransmisssions)


> (2) Section 4
> OLD The initial pool of expert and the review criteria are outlined
> below. NEW The review criteria are outlined below.
> The initial pool of experts is not designated by this draft.

good catch

> Nits/editorial comments:
> Section 3
> OLD The following ABNF productions represent reserved values and
> names NEW The reserved element defined by the following ABNF
> productions represents a set of reserved values and names


> Section 4
> The registry is to be operated under the "Designated Expert
> Review" policy from RFC5226 [RFC5226] employing a pool of experts
> Nope, the actual RFC5226 name of that well-known IANA policy is
> Expert Review (or Designated Expert), see section 4.1 of RFC5226.
> If that well-known IANA policy isn't what was intended, this is a
> serious open issue.

that IANA policy was indeed intended.

> Top of p.7 The presense of an entry in the registy MUST NOT be
> taken to imply ^ r ---------------------------------------/

Here I actually want normative language. It is quite important that the
registry not be over-interpreted.

> Section 7
> OLD An implementor of MUST NOT treat the registry as a trust
> framework or NEW A protocol implementor MUST NOT treat the registry
> as a trust framework or

I actually don't mean protocol implementor here. I mean consumer of the

> The minor issue about RFC 2119 keywords also applies to this text.

This is another case where I think I disagree!

> idnits 2.12.13 did not find any nits that need attention.
> Thanks, --David

thank you!

	Cheers Leif

> ---------------------------------------------------- David L.
> Black, Distinguished Engineer EMC Corporation, 176 South St.,
> Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508)
> 293-7786        Mobile: +1 (978) 394-7754 
> ----------------------------------------------------

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -