>>>>> "tshields" == tshields <[email protected]> writes:
Hi.
most of your comments were editorial wording comments and can be
addressed in editing the document.
We appreciate both the editorial comments and the more technical
comments I'm responding to in this message.
tshields> Section 5.3.2, Paragraph 2 and Paragraph 4
>> The following methods are sufficient:
>>
>> o NAS identity in trusted digitally signed request.
>>
>> o NAS identity in trusted SAML federation metadata.
>> The following methods are sufficient:
>>
>> o RADIUS realm in trusted digitally signed request.
>>
>> o RADIUS realm in trusted SAML federation metadata.
tshields> The wording here makes it unclear whether one of these
tshields> alone is sufficient or whether both are
tshields> required. Rewording to say something like "Satisfying the
tshields> following two conditions is sufficient:" is more clear.
Sticking the information either in metadata or in the SAML message is
sufficient, both is not required.
tshields> Section 7.4.3, Bullet 3
>> If a <saml:AuthnStatement> used to establish a security context
>> for the Principal contains a SessionNotOnOrAfter attribute, the
>> security context SHOULD be discarded once this time is reached,
>> unless the service provider reestablishes the Principal's
>> identity by repeating the use of this profile.
tshields> Why is this a SHOULD and not a MUST? If it is a SHOULD
tshields> merely to allow for the situation described above (where
tshields> the service provider reestablishes the identity), then it
tshields> actually should be a MUST. "The security context MUST be
tshields> discarded unless the service provider reestablishes the
tshields> Principal's identity" is a perfectly sound requirement.
Well, we've found in the GSS community that the user experience of
ending some sorts of sessions prematurely is sufficiently bad that
everyone has gone out of their way not to do it. For example if you're
in the middle of downloading a file, it's far better to finish that than
to kill your session because it reached an authentication time out.
We're hoping to make the text in this draft consistent with what people
will do rather than an ideal that would break stuff.
The Kerberos community went through a lot of pain convincing themselves
to do this over the years, and so that's where we're taking this from.
It's certainly something that we can discuss if we think our
requirements are different.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
