On 10/16/14 7:56 AM, Brian Campbell wrote:
Thanks for your review and feedback on this one too, Pete. Replies are
inline below...
On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick
<presn...@qti.qualcomm.com <mailto:presn...@qti.qualcomm.com>> wrote:
2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119.
Apologies for any haphazardness.
No worries. As you've discovered, throughout the organization we're
pretty bad about consistent use of it, so if you use other RFCs for
examples, you get weird results. I'm very happy to see that you're
trying to get this right.
But the
second one buries what *might* be a proper and important use of
MUST (you
MUST NOT try to stick in two SAML Assertions) with a simple
definitional
one. (And that assumes that it's even plausible to try to use more
than
one SAML Assertion. If you simply can't, it's just s/MUST
contain/contains.)
It's intended to be both definitional and restrictive - that it
contains an assertion but not more than one.
The Response document in SAML Web SSO allows for multiple assertions
and it has turned out to be quite a pain to deal with in practice
while not adding any real value. While it's not entirely clear how one
might try and stick more than one assertion in this parameter given
the serialization, I still wanted to explicitly preclude it.
Ah, good. Then some sort of MUST is appropriate.
Given that explanation of the intent, would you suggest an alternative
wording of that sentence? Or is it okay as is?
I think it's OK as is, but would be better if you had the requirement on
the right thing:
The value of the "assertion" parameter contains a single SAML 2.0
Assertion. It MUST NOT contain more than one SAML 2.0 assertion.
That makes it clear that you're not simply saying "Put the SAML 2.0
Assertion in here." You're saying, "Don't try to squeeze in more than one."
The base64url encoding MUST is fine, because you don't
want people sticking in raw XML, but the SHOULD NOTs for line wrapping
and pad I am curious about: Isn't a parser going to have to check for
line wrapping and pad anyway and undo it (because it's not a MUST
NOT),
and therefore this SHOULD NOT really isn't about interoperability
so much
as neatness (in which case they SHOULD NOTs are not appropriate)?
Yes, the base64 decoder still has to be prepared to deal with line
wrapping and padding. In my experience most decoders are very capable
of it. And stripping the white-space and "="s prior to decoding is
easy enough for those using a decoder that can't.
The SHOULD NOT is about neatness but also in a way about interop in
that it's intended to help avoid common implementation problems that
can arise with urlencoding the parameter value (either not encoding or
double encoding, etc.). Base64url without line wraps and padding
dosn't need urlencoding and doesn't change if urlencoding is applied.
That was the thinking behind the SHOULD NOTs there.
As I try and articulate the reasoning, it does feel like maybe it
should have been a MUST NOT. I guess I was looking to channel Postel a
bit in being somewhat liberal in what is accepted with padding/no
padding and line wraps/no line wraps while using the SHOULD NOTs to
suggest that clients be conservative in what they send.
Thoughts about what to do with it, given that reasoning?
I agree with your gut: If implementations are going to bump into other
implementations that fail to encode properly or double encode when
encountering line wraps and padding, then you should say MUST NOT. You
might even want to say, "Due to some poor implementations, you MUST NOT
use line wrapping or padding when you create these things, but you MUST
decode them if you receive them".
3 - Subpoint 2: Just for clarification, I like the non-passive
sentence
better: "The Authorization Server MUST reject any assertion that
does not
contain its own identity as the intended audience."
Yes, on seeing it written that way, I also like it better.
Just to make sure I'm on the same page. The sentence you suggest would
replace the second to last sentence in #2 that currently says,
"Assertions that do not identify [...] MUST be rejected."?
Correct.
Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not
conflicting? Can you not have an authenticated subject with an
autonomously acting client?
Perhaps I've misused the words but, yes, that's the idea. An
autonomously acting client is meant to describe a client that's acting
without the user being present. The act of direct user authentication
with the assertion issuer seems like the way to differentiate between
the user being present for things and the client doing things "in the
background" for the user. Both are valid use cases. Item 7 is looking
to provide the AS with some clue as to which is happening.
Ah, so what you mean by "the Assertion issuer authenticated the subject"
is specifically that there was user interaction and *not* an
autonomously acting client. I didn't read the first sentence that way.
I'm open to suggestions to clarify the text but I do believe there's
no conflict.
Maybe just saying "directly authenticated" in the first sentence or
something like that. But this may be obvious to someone who's
implementing, so entirely up to you.
Thanks for the rest.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
