<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes the idea is to use JWS to avoid directly disclosing the secret as is done with basic in the symmetric key case.<div><br></div><div>OAuth dosent define a asymetric authentication to the token endpoint.</div><div><br></div><div>The plan was to define a JWT with a single claim of code that would be signed by the RP.</div><div><br></div><div>We should probably drop this or fully explain it.</div><div><br></div><div>John B.<br><div><div><div>On 2011-08-24, at 12:56 AM, Andreas Åkre Solberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">REDIRECT-05 Section 3.1.5 mentions the secret_type JWT:<div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: 13px; ">If the secret_type is <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; text-align: -webkit-auto; text-decoration: none; text-indent: 0px; text-rendering: auto; text-shadow: none; text-overflow: clip; text-transform: none; color-interpolation: srgb; color-interpolation-filters: linearrgb; color-rendering: auto; text-anchor: start; ">"basic"</tt>, send the pre-shared secret. If the secret_type is <tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; text-align: -webkit-auto; text-decoration: none; text-indent: 0px; text-rendering: auto; text-shadow: none; text-overflow: clip; text-transform: none; color-interpolation: srgb; color-interpolation-filters: linearrgb; color-rendering: auto; text-anchor: start; ">"JWT"</tt>, send the compact serialization of the <a shape="rect" href="file:///Users/andreas/Library/Application%20Support/Evernote/data/101370/content/p3310/#JWT" style="color: rgb(153, 0, 0); font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: bold; text-align: -webkit-auto; text-decoration: none; text-indent: 0px; text-rendering: auto; text-shadow: none; text-overflow: clip; text-transform: none; color-interpolation: srgb; color-interpolation-filters: linearrgb; color-rendering: auto; text-anchor: start; ">JWT</a> [JWT] Signature over the 'code'.</span></blockquote><br></div><div>Is this method described somewhere in more details?</div><div><br></div><div>It says JWT signature, but there is no JSON input? Does it mean JWS signature over the code string?</div><div><br></div><div>Getting the consumer to sign something that the Provider presents, may be risky. May be not if a shared key is used, but if the consumer have a key-pair that it uses against multiple services. I'm thinking that the Provider can get a consumer to sign a code that the provider has received from a different provider; being able to impersonate the user.</div><div><br></div><div>Andreas</div></span></blockquote></div><br></div></div></body></html>