<html>
<head>
<meta name="generator" content="Windows Mail 17.5.9600.20315">
<style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir="ltr">
<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>The use case is now well identified.</div><div><br></div><div>Its similar in spirit to features of current Microsoft-cloudland: enabling one directory to issue an administrator-grade assertion that signs up that entire IDP security domain and authorize reliance of the IDP-issued *user* assertions by some third party app, running its own sp-centric security domain.</div><div><br></div><div>If a user has already several scopes aligned with his/her identity, at an IDP/grant manageing party, one scope per RP domain authorized to rely, then one can well imagine issued a “combined JWT” with all such scopes. That would be consumed by a tenant-independent independent guard/mediator in a cloud, deciding whether or not to allow passage of the flow onto desired he tenant managed by said cloud, who must be listed in the scopes now aggregated.</div><div><br></div><div>I probably didn't say that well, but I get it. THANKS. Its for the cloud tenant-signup and reliance by only-authorized tenant-RPs use cases. Its the double-headed hydra of provisioning trust relations between idp-class and RP-class security domains, much as in the older world of issuing cross-certificates in military-class PKIs. In the cloud case, one has cloud-fabric itself deliver the guarding the policy relations, on behalf of a few million less-capable tenants now relieved of such provisioning management and reliance-authorized duties.</div><div><br></div><div><br></div><div data-signatureblock="true"><div><br></div><div>Sent from Surface Pro</div><div><br></div></div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style='line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;'><b>From:</b> <a href="mailto:cmortimore@salesforce.com" target="_parent">Chuck Mortimore</a><br><b>Sent:</b> Thursday, January 23, 2014 2:19 PM<br><b>To:</b> <a href="mailto:home_pw@msn.com" target="_parent">peter Msn</a><br><b>Cc:</b> <a href="mailto:ve7jtb@ve7jtb.com" target="_parent">John Bradley</a>, <a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></font></div></div><div><br></div><div dir=""><div dir="ltr"><div>What you've build is a pretty common use-case for us as well, and broadly used in our customer base (some minor variations in protocol, but same intent) Here's a whitepaper we use to explain the websso /oauth hybrid approach to customers: <a href="http://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth" target="_parent">http://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth</a></div>
<div><br></div><div>The bearer flows are used for slightly different use-cases, at least in our environment. We tend to employee these for server-to-server use-cases where the user is not present (and not able to go through an oauth or websso flow) but you still need to obtain an access token on their behalf. One practical example is automated provisioning of tenants. Using our signup API you can create a new salesforce tenant with an admin that is pre-approved for a particular oauth application. You can than use the bearer flow to exchange an assertion for an access token and begin programmatically configuring the tenant. No exchange of passwords, and no user present to physically perform the oauth dance. </div>
<div><br></div><div>One example, but hopefully this helps illustrate how they can be used. </div><div><br></div><div>-cmort</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 1:24 PM, Peter Williams <span dir="ltr"><<a href="mailto:home_pw@msn.com" target="_parent">home_pw@msn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir="ltr">
<div style='font-family: "Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;' dir="ltr"><div><br></div>
<div><div>Say just a little more, since this swapping of “enterprise” issued (saml blob) tokens all overlaps with openid connect in my mind - where the latter has different type of jwt: one for passing (classical oauth-powered) access guards at webapis, and those one's delivering identity claims and attributes from a backroom directory.</div>
<div> </div><div>Ive built and deployed a websso and oauth hybrid. Invoking authorization via a (embedded)Brower requires one to conclude websso, with a wsfedp idp, that mints saml tokens. Said token opens the consent gate, that controls minting of oath grants. Subsequently, Use of token endpoint, citing a one time code or other proof token, returns a Json object with one or more jwts, and the websso bearer token, and an microsoftonline sts-issued(swapped from bearer) token usable at office365 wstrust/wssecurity/wssecureconversation guarded APIs. </div>
<div><br></div><div>thick clients, phone apps, tablet apps and websites acting as agents are all happy with all that. And it fits with today's devices and middleware now (finally) adopted by us realty, and its 300 vendors.</div>
<div><br></div><div>What the oath bearer grant has done is confuse me more, particularly in understanding how the scopes from grants are aggregated, and WHY. I already don't really get how I'm supposed * to use* different jwts, in the openid connect profile, for “radically innovative” use cases that align with how folks are assuming enterprise, and social, and APIs, and mixed app\browser apps are all supposed to work, next generation.</div>
<div><br></div><div>Prehaps a call for a blog post or two?</div><div><br></div><div>Sent from Surface Pro</div><div><br></div></div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style='line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;'><b>From:</b> <a href="mailto:ve7jtb@ve7jtb.com" target="_parent">John Bradley</a><br>
<b>Sent:</b> Thursday, January 23, 2014 11:34 AM<br><b>To:</b> <a href="mailto:home_pw@msn.com" target="_parent">peter Msn</a><br><b>Cc:</b> <a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></font></div>
</div><div><div class="h5"><div><br></div><div dir=""><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" target="_parent">http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer</a> and <a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-" target="_parent">http://tools.ietf.org/html/draft-ietf-oauth-assertions</a></div>
<div><a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-" target="_parent"><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" target="_parent">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" target="_parent">home_pw@msn.com</a>> wrote:</div>
<br><blockquote style="margin-top: 0px; margin-bottom: 0px;"><div style="font: 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; font-size-adjust: none; font-stretch: normal;" dir="ltr">
<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><div>Sent from Surface Pro</div><div><br></div></div>_______________________________________________<br>
general mailing list<br><a href="mailto:general@lists.openid.net" target="_parent">general@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_parent">http://lists.openid.net/mailman/listinfo/openid-general</a></div>
</blockquote></div><br></div></div></div></div></div>
</div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net" target="_parent">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_parent">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br></blockquote></div><br></div>
</div></div>
</body>
</html>