Subject: [OAUTH-WG] WGLC on Assertion Drafts

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 5 Apr 2012 17:46:57 +0300

Hi all, 

this is a Last Call for comments on these three documents:
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10
http://tools.ietf.org/html/draft-ietf-oauth-assertions-01
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02

Please have your comments in no later than April 23rd.

Do remember to send a note in if you have read the document and have no
other comments other than "it's ready to go" - we need those as much as
we need "I found a problem".

Thanks!
Hannes & Derek

---

From: Justin Richer <[email-masked]>
Date: Thu, 5 Apr 2012 12:53:23 -0400

> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01

Section 7's second portion about a client including multiple credentials 
types seems buried down here in the Error Responses section for 
something this fundamental. It also conflates discussion of selection of 
this client authorization type in here, where it ought to be in its own 
section, closer to the top.

> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02
This one seems fine to me, very straightforward.

> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10

As I try to avoid SAML in general, I'm not a good person to comment on 
this draft.

  -- Justin

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 5 Apr 2012 15:33:51 -0500

Hello,

The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, section 6.1 has the following requirement:
The Authorization Server MUST validate the assertion in order to
      establish a mapping between the Issuer and the secret used to generate the assertion.

I thought that checking a signature is a part of the assertion validation, which cannot be done without knowing the mapping between the issuer and the secret used to generate the assertion.
It appears that the quoted text requires validation of the assertion prior to checking the signature.
What am I missing?

Zachary

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, April 05, 2012 10:47 AM
To: [email-masked]
Subject: [OAUTH-WG] WGLC on Assertion Drafts

Hi all,

Do remember to send a note in if you have read the document and have no other comments other than "it's ready to go" - we need those as much as we need "I found a problem".

Thanks!

Hannes & Derek

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Apr 2012 16:14:21 -0600

Thanks Justin, a couple comments/questions are inline...

On Thu, Apr 5, 2012 at 10:53 AM, Justin Richer <[email-masked]> wrote:
> types seems buried down here in the Error Responses section for something
> this fundamental.

Yeah, I can see that. Although the restriction on multiple client
authentication methods is actually inherited from core OAuth (last
sentence in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3)
so maybe there shouldn't even normative language about it in this doc?

> It also conflates discussion of selection of this client
> authorization type in here, where it ought to be in its own section, closer
> to the top.

I'm not sure I follow you here? As I re-read §7 I think it might make
sense to break it into two pieces, one on grants and one on client
auth.  Maybe a 7.1 and a 7.2 or maybe subsections of §4, like a §4.1.1
for client authentication errors and §4.2.1 for authz/grant errors.
But I don't think that was what your comment was about?

Was your comment that this text should live somewhere else?
  "Token endpoints can differentiate between assertion based
   credentials and other client credential types by looking for the
   presence of the client_assertion and client_assertion_type attributes
   which will only be present when using assertions for client
   authentication."

I wouldn't disagree with you there, if that was the case.

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 13 Apr 2012 10:20:10 -0700

Hi Zachary - sorry about the delay in responding.

Perhaps the language is a bit confusing - let me explain the intent and see if it makes sense and if you have a recommendation on how it could be made clearer.

All this is really saying is that the Authorization server must validate the signature to make sure the Issuer is who they say they are.   The authorization server would use the Issuer as it's mechanism for looking up either the shared secret for an HS256 or the public key for RS256.   It then checks the signature, and proves to itself that the generator of the assertion had possession of the expected keying material and identified itself as the issuer.

Feedback welcome

-cmort

On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" <[email-masked]> wrote:

Hello,

Zachary

Hi all,

Thanks!

Hannes & Derek

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 13 Apr 2012 13:55:18 -0500

Chuck,

The intent is clear. Perhaps the following change would clarify the text:
Old: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generate the assertion.
New: The Authorization Server MUST validate the assertion's signature in order to verify the Issuer of the assertion.

Zachary

From: Chuck Mortimore [mailto:[email-masked]]
Sent: Friday, April 13, 2012 1:20 PM
To: Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts

Feedback welcome

-cmort

Zachary

Hi all,

Thanks!

Hannes & Derek

---

From: Brian Campbell <[email-masked]>
Date: Mon, 23 Apr 2012 06:35:36 -0600

Just a note (to myself as much as anything) that that same text is also in
§6.2, §6.3 & §6.4 and should updated for all occurrences.

On Fri, Apr 13, 2012 at 12:55 PM, Zeltsan, Zachary (Zachary) <
[email-masked]> wrote:

> Chuck,****
>
> ** **
>
> The intent is clear. Perhaps the following change would clarify the text:*
> ***
>
> Old: The Authorization Server MUST validate the assertion in order
> to establish a mapping between the Issuer and the secret used to generate
> the assertion.****
>
> New: The Authorization Server MUST validate the assertion’s signature in
> order to verify the Issuer of the assertion.****
>
> ** **
>
> Zachary****
>
> ** **
>
> ** **
>
> *From:* Chuck Mortimore [mailto:[email-masked]]
> *Sent:* Friday, April 13, 2012 1:20 PM
> *To:* Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo);
> [email-masked]
> *Subject:* Re: [OAUTH-WG] WGLC on Assertion Drafts****
>
> ** **
>
> Hi Zachary – sorry about the delay in responding.
>
> Perhaps the language is a bit confusing – let me explain the intent and
> see if it makes sense and if you have a recommendation on how it could be
> made clearer.
>
> All this is really saying is that the Authorization server must validate
> the signature to make sure the Issuer is who they say they are.   The
> authorization server would use the Issuer as it’s mechanism for looking up
> either the shared secret for an HS256 or the public key for RS256.   It
> then checks the signature, and proves to itself that the generator of the
> assertion had possession of the expected keying material and identified
> itself as the issuer.
>
> Feedback welcome
>
> -cmort
>
> On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" <
> [email-masked]> wrote:****
>
> Hello,
>
> The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01,
> section 6.1 has the following requirement:
>
> I thought that checking a signature is a part of the assertion validation,
> which cannot be done without knowing the mapping between the issuer and the
> secret used to generate the assertion.
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo)
> *Sent:* Thursday, April 05, 2012 10:47 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] WGLC on Assertion Drafts
>
> Hi all,
>
> other comments other than "it’s ready to go" - we need those as much as we
> need "I found a problem".
>
> Thanks!
>
> Hannes & Derek****
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>