<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>This is the openID list and not a OAuth list, but I will attempt an answer.</div><div><br></div><div>For others on the list the specs are <a href="http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer">http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer</a> and <a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-">http://tools.ietf.org/html/draft-ietf-oauth-assertions</a></div><div><a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-"><br></a>Basically it is a way to do token translation. In some cases when interfacing with Enterprise systems getting them to issue a SAML token may be easier the simplest thing to do.</div><div><br></div><div>The resource server (RS) however likely only understands a single access token form. GUID or JWT for the most part. The assertion profiles let the client translate a JWT or SAML assertion into a OAuth access token.</div><div><br></div><div>This can be quite useful in crossing security domains where the AS is relying on a 3rd party to authenticate the user. The AS could redirect to a SAML IDP using websso but on mobile devices that might not be optimal. </div><div><br></div><div>The scopes associated with the access token can be a subset of the ones granted by the SAML assertion. In some cases with multiple endpoints you may want to <a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-13#section-4.1">down scope the access token</a>.</div><div><br></div><div>The biggest user of this flow is SalesForce as far as I know.</div><div><br></div><div>John B.</div><div><br><div><div>On Jan 23, 2014, at 3:46 PM, Peter Williams <<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div data-externalstyle="false" dir="ltr" style="font-family: Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', sans-serif; font-size: 12pt;"><div>It took me a while (and several years of lateness) to comprehend just what kind of world the classical oauth grants were designed for. One advantage of being late to the party was that I tended to get better variants, such as a grant returning a JWT bearing attributes rather than using grants that returnee guids as tokens - that had to be subsequently resolved.</div><div><br></div><div>So what is the “use case” of the saml2 bearer assertion grant?</div><div><br></div><div>I makes perfect sense that someone with a bearer assertion might swap it for a JWT, for use at APIs. And it makes perfect sense that such a saml assertion plays much the same role as a does possession of an optional renewal-token - the one native to an OAUTH handshake.</div><div><br></div><div>But I don't see what the “generation changing” motivation is for the scopes - that the access token returns all scopes for which tokens (with renewals) have previous been issued.</div><div><br></div><div>So what is the 'context’ of control being enabled here? What thing is this scope-aggregation feature working for?</div><div><br></div><div><br></div><div data-signatureblock="true"><div>Sent from Surface Pro</div><div><br></div></div></div>_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a></div></blockquote></div><br></div></body></html>