Are you kidding me? "Not the best spelled out feature"? It is not spelled at all. Not using a single character! Maybe Dick was using magic ink for this section.
Here are the facts: The WRAP specification does not preclude the usage of 2 assertions. V2 does not preclude the usage of 2 assertions. WRAP supports additional parameters. V2 supports additional parameters. V2's support for 2 assertions is IDENTICAL to that of WRAP. Whatever code is running at Microsoft is clearly not based on any *published* specification presented to this working group. EHL From: Anthony Nadalin [mailto:tony...@microsoft.com] Sent: Friday, April 22, 2011 3:45 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 Not sure I have to show you anything. The WRAP specification does not preclude the usage of 2 assertions as this was one of the must support use cases for WRAP. As I indicated this was not the best spelled out feature in the WRAP specification. Yaron's append was an attempt to clarify the use case with additional text. If you want to come on site you can see the code and the dates on the code that predates Yaron's text. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, April 22, 2011 3:40 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 Let me make sure we're clear here: Your argument is that this is not a new use case because WRAP allows 'additional parameters' and doesn't explicitly forbids it? If I missed something, please quote the exact normative language in WRAP showing how to use two assertions, or any text differentiating between using an assertion for client authentication vs. using an assertion for resource owner authorization. Show me anything that pre-dates Yaron's text documenting the two assertions use case. EHL From: Anthony Nadalin [mailto:tony...@microsoft.com]<mailto:[mailto:tony...@microsoft.com]> Sent: Friday, April 22, 2011 3:34 PM To: Eran Hammer-Lahav; Dick Hardt Cc: OAuth WG Subject: RE: [OAUTH-WG] Revised Section 3 I disagree here, this is not new or even completely new use case as this was in WRAP as we are using this feature now. I would agree that it's not very well documented but that was attempted by Yaron in his append was to clarify the support. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]<mailto:[mailto:e...@hueniverse.com]> Sent: Friday, April 22, 2011 3:25 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3 From: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>> Date: Fri, 22 Apr 2011 14:51:33 -0700 AJN-> So the client credentials originate from WRAP also, it's not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The section 5.2 (and subsections) in the WAP specification is where you see the assertion documented but what is not explicitly stated (other than additional parameters clause)there but not disallowed is the ability to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRAP for authentication It is completely new. The two assertions functionality is certainly NOT in WRAP. It is not even hinted at. Seems to me you just made my case for dropping this issue. If this is your rational for adding two assertions support in v2, then we can be done right now. v2 already gives you the exact same 'additional parameters' support and does not disallow two assertions. You have made statements in the past that WRAP did everything you needed and that v2 has to cover the same scope. Well, it already does. We can certainly continue to debate whether v2 needs to address this new use case, and if so how to accomplish it, but that is based solely on new requirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0). EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
