Authentication Context Certificate Extension
RFC 7773

-- Section 3.1.1 --

   The <AuthContextInfo> element may hold any number of child elements
   of type any (processContents="lax"), providing additional information
   according to local conventions. Any such elements MAY be ignored if
   not understood.

What else can be done with such elements that are not understood, other than to ignore them?  That is, why is it "MAY be", rather than, say, "are"?  (The same question applies to Section 3.1.2.)

-- Section 3.1.2 --

            String representations of object identifiers (OID) in the
            Ref attribute MUST be represented by a sequence of integers
            separated by a period. E.g. "2.5.4.32". This string MUST NOT
            contain any white-space or line breaks. 

That's a very limited MUST not, and it doesn't say what other characters can appear in the string.  Is it actually the case that "This string contains only numerals (ASCII 0x30 to 0x39) and periods (ASCII 0x2E), and MUST NOT contain any other characters." ?  If so, wouldn't it be better to say it that way?

I was notified that Kathleen has the status issue well in hand, so I am removing my DISCUSS on that point.

I tend to agree with Stephen's point about the usefulness of this as a standard (if it is supposed to be ST).

Authors should probably note a couple of minor editorial issues that were raised by Jouni Korhonen in his Gen-ART review.

Eric Vynke performed the opsdir review.

Just as a nit, this document uses "certificate" with no qualification. Most of the documents in the references say "X.509 certificates". Is "certificate" sufficiently disambiguated with no qualifiers?

- This is not the kind of thing that is particularly useful,
as (IMO) it's over generalised and will not be supported
widely. I think you'd have been better off simply saying what
you have done in the Swedish eID system. (Mind you, I also
think that's over complex too;-) However, I've no objection to
this as I guess it's a little useful to your eID project, and
not harmful elsewhere. (It'd be better though if you said that
you didn't claim that this is highly scalable etc.)

- I think this'd be better if you said the extension MUST be
critical. That'd eliminate the (real, but not huge) concern
that the code for all this (being mostly unused) could be 
harmful. Not a huge deal though.

- "A unique reference to the authentication instant" Huh?
What's that mean?

- "The extension defined here provides better scalability..."
I don't buy that fwiw. One needs the code to intepret all
these (overly) abstract data structures.

- p8, "This string MUST NOT contain any white-space or line
breaks." I have no idea why that MUST NOT is needed given how
much other fluff can be in XML string encodings.

- p9, "Any such elements MAY be ignored if not understood."
Huh? If I don't understand what else can I do but igore?

- I think it'd be useful to say that implementations really
ought not decode then re-encode all this stuff as there are
too many way to get that wrong. (If you tell me that's
considered obvious nowadays, I'm fine with that.)

- The secdir review [1] makes some points similar to those
above. I think that deserves a response, even if I don't
consider those points require a DISCUSS ballot.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06124.html