Thanks Kathleen, that makes sense. I do, however, think that a little 'should' would be more appropriate there than a big 'SHOULD' as there's no other use of RFC2119 language in that text. That okay by you? It would read like this:
A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as TLS. In cases where it’s desirable to prevent disclosure of certain information the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the authorization server. Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information in an Assertion (typically by limiting what information is included in an <AttributeStatement> or omitting it altogether). In some cases the Subject can be a value representing an anonymous or pseudonymous user as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [*http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1 <http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1>*]. On Sat, Jul 19, 2014 at 8:24 AM, Kathleen Moriarty < [email protected]> wrote: > Thanks for the quick response, Brian. I think the text looks great. The > only change I'd like to suggest is in the second sentence, to change the > 'may' to 'SHOULD'. > > Best regards, > Kathleen > > Sent from my iPhone > > On Jul 19, 2014, at 1:00 AM, Brian Campbell <[email protected]> > wrote: > > How about the following (which is intentionally similar to the text I just > put forth for your request for privacy consideration in > draft-ietf-oauth-jwt-bearer-09)? > > A SAML Assertion may contain privacy-sensitive information and, to prevent > disclosure of such information to unintended parties, should only be > transmitted over encrypted channels, such as TLS. In cases where it’s > desirable to prevent disclosure of certain information the client, the > Subject and/or individual attributes of a SAML Assertion may be encrypted > to the authorization server. > > Deployments should determine the minimum amount of information necessary > to complete the exchange and include only that information in an Assertion > (typically by limiting what information is included in an > <AttributeStatement> or omitting it altogether). In some cases > the Subject can be a value representing an anonymous or pseudonymous user > as described in Section 6.3.1 of the Assertion Framework for OAuth 2.0 > Client Authentication and Authorization Grants > [*http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1 > <http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1>* > ]. > > > On Tue, Jul 15, 2014 at 2:04 PM, Kathleen Moriarty < > [email protected]> wrote: > >> Hello, >> >> I just finished my review of >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer. The >> draft looks great, thank you for all of your efforts on it! >> >> I did notice that there were no privacy considerations pointing back to >> RFC6973, could that text be added? The draft came after the Oauth >> framework publication (refernced in the security considerations), so I am >> guessing that is why this was missed as there are privacy considerations in >> the oauth assertion draft (I competed that review as well and the draft >> looked great. I don't have any comments to add prior to progressing the >> draft). >> >> Thank you. >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
