Re: [OAUTH-WG] Review of Assertions drafts

2012-11-07 Thread Brian Campbell
Fixed that one in -15 of the SAML draft. Thanks for the review.

FWIW, the requirement about only one client authentication mechanism being
used actually comes from core OAuth at
http://tools.ietf.org/html/rfc6749#section-2.3 and is worded pretty
strongly there where it says, The client MUST NOT use more than one
authentication method in each request.


On Tue, Nov 6, 2012 at 2:46 PM, Anganes, Amanda L aanga...@mitre.orgwrote:

   Good catch, thanks for double-checking.

  --Amanda

   From: Mike Jones michael.jo...@microsoft.com
 Date: Tuesday, November 6, 2012 4:40 PM
 To: Anganes, Amanda L aanga...@mitre.org, oauth@ietf.org 
 oauth@ietf.org
 Subject: RE: Review of Assertions drafts

   Amanda wrote: [3] Section 2.2 first sentence: client authentication
 grant should just be client authentication.

 ** **

 This change should also be applied to the first sentence of 2.2 in SAML
 draft, where the same phrase occurs.

 ** **

 -- Mike

 ** **

 *From:* oauth-boun...@ietf.org 
 [mailto:oauth-boun...@ietf.orgoauth-boun...@ietf.org]
 *On Behalf Of *Anganes, Amanda L
 *Sent:* Tuesday, November 06, 2012 12:41 PM
 *To:* oauth@ietf.org
 *Subject:* [OAUTH-WG] Review of Assertions drafts

 ** **

 Hannes requested that some folks read through the assertion drafts and
 give feedback in light of the upcoming shepherd review.

 ** **

 [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
 [2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
 [3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

 ** **

 I can't speak to the security considerations or advisability of these
 drafts, but as far as the documents go I think they are well-organized,
 consistent (internally and across all 3 documents) and straightforward. **
 **

 ** **

 A few comments:

 ** **

 [1] Section 4.2.1 says in passing that it is an error condition if more
 than one client authentication mechanism is used. If this is a true
 requirement / error state I think it should be called out more strongly.
 Perhaps 4.2 should say at the top that Other client authentication
 mechanisms MUST NOT be used in conjunction with an assertion. 

 ** **

 If so, [2] 3.2 and [3] 3.2 should also indicate that additional client
 credentials MUST NOT be used in addition to the assertion for Client
 Authentication.

 ** **

 [3] Section 2.2 first sentence: client authentication grant should just
 be client authentication.

 ** **

 --Amanda Anganes

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


[OAUTH-WG] Review of Assertions drafts

2012-11-06 Thread Anganes, Amanda L
Hannes requested that some folks read through the assertion drafts and give 
feedback in light of the upcoming shepherd review.

[1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
[2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
[3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

I can't speak to the security considerations or advisability of these drafts, 
but as far as the documents go I think they are well-organized, consistent 
(internally and across all 3 documents) and straightforward.

A few comments:

[1] Section 4.2.1 says in passing that it is an error condition if more than 
one client authentication mechanism is used. If this is a true requirement / 
error state I think it should be called out more strongly. Perhaps 4.2 should 
say at the top that Other client authentication mechanisms MUST NOT be used in 
conjunction with an assertion.

If so, [2] 3.2 and [3] 3.2 should also indicate that additional client 
credentials MUST NOT be used in addition to the assertion for Client 
Authentication.

[3] Section 2.2 first sentence: client authentication grant should just be 
client authentication.

--Amanda Anganes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] Review of Assertions drafts

2012-11-06 Thread Anganes, Amanda L
Good catch, thanks for double-checking.

--Amanda

From: Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
Date: Tuesday, November 6, 2012 4:40 PM
To: Anganes, Amanda L aanga...@mitre.orgmailto:aanga...@mitre.org, 
oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: Review of Assertions drafts

Amanda wrote: [3] Section 2.2 first sentence: client authentication grant 
should just be client authentication.

This change should also be applied to the first sentence of 2.2 in SAML draft, 
where the same phrase occurs.

-- Mike

From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Anganes, Amanda L
Sent: Tuesday, November 06, 2012 12:41 PM
To: oauth@ietf.orgmailto:oauth@ietf.org
Subject: [OAUTH-WG] Review of Assertions drafts

Hannes requested that some folks read through the assertion drafts and give 
feedback in light of the upcoming shepherd review.

[1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
[2] http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
[3] http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

I can't speak to the security considerations or advisability of these drafts, 
but as far as the documents go I think they are well-organized, consistent 
(internally and across all 3 documents) and straightforward.

A few comments:

[1] Section 4.2.1 says in passing that it is an error condition if more than 
one client authentication mechanism is used. If this is a true requirement / 
error state I think it should be called out more strongly. Perhaps 4.2 should 
say at the top that Other client authentication mechanisms MUST NOT be used in 
conjunction with an assertion.

If so, [2] 3.2 and [3] 3.2 should also indicate that additional client 
credentials MUST NOT be used in addition to the assertion for Client 
Authentication.

[3] Section 2.2 first sentence: client authentication grant should just be 
client authentication.

--Amanda Anganes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth