<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The standard id_token issued in connect is an assertion to the client about the Web SSO session that it relates to, and contains some additional security information. The audience for the token is the client.<div><br></div><div>To swap a JWT/id_token for a access token issued from an external AS you need a JWT/id_token with that AS as the audience.</div><div><br></div><div>That can be requested with a refresh token from the token endpoint if the AS is supporting side scoping (issuing a token to a client with something other than the client as the audience).</div><div>If it is supported then side scoped security token is issued with the authenticated requester indicated in the "azp" claim and the target audience or audiences in "aud".</div><div><br></div><div>This currently exists in the Google Play store on Android where native apps ask Google for a JWT/id_token asserting the subject that they can pass to there OAuth backends.</div><div><br></div><div>So the Trust in that case is the app authors OAuth server decides to whitelist Google's JWT/id_tokens to accept as valid. </div><div><br></div><div>The Google public-key is available in a JWKS at a discoverable location based on the issuer "iss".</div><div><br></div><div>So in Connect all assertions have a "iss" and the value of that MUST be a https URL, signing and encryption keys as well as other IdP configuration parameters are discoverable based on that.</div><div><br></div><div>Some may choose not to trust TLS security and use a trusted meta-data service or exchange keys out of band.</div><div><br></div><div>I can't say if Microsoft Azure will start issuing cross security domain id_tokens. any time soon.</div><div><br></div><div>There is more work happening with with this in the native applications WG. <a href="http://openid.net/wg/napps/">http://openid.net/wg/napps/</a></div><div><br></div><div>To scale OAuth across trust domains something like this is inevitable. It is however still in its early stages. </div><div>OAuth on its own has a very simple trust model between a AS and RS with no notion of identity or federation.</div><div><br></div><div>John B.</div><div><br><div><div>On Jan 29, 2014, at 1:29 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>Perhaps there is one more topic, relevant to strategic understanding, timing and planning.</div><div><br></div><div>Now we understand that the id-token jwt issued by an AS, accompanying the access token whose grant authorizes the requesting client_id’s endpoint, can be swapped at another AS for a second access token, grant for some other domain’s endpoint(s). Thus, a user with microsoftaccount can get tokens to use<span class="Apple-converted-space"> </span><a href="http://hotmail.com/">Hotmail.Com</a><span class="Apple-converted-space"> </span>APIs AND MIGHT swap the accompanying id_token at Google to get tokens for use at a <a href="http://gmail.com/">Gmail.Com</a><span class="Apple-converted-space"> </span>API.</div><div><br></div><div>Obviously<span class="Apple-converted-space"> </span><a href="http://gmail.com/">Gmail.Com</a><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><a href="http://hotmail.com/">Hotmail.Com</a><span class="Apple-converted-space"> </span>have to have a trust relationship, expressed and setup somehow. Does opened connect state HOW such trust relationships are to be setup? (or does one just share signed saml2 metadata files, and cert roots, as traditional?)</div><div><br></div><div>Now a rather Microsoft-y question. In windowsland we all have oauth2 endpoints, for our tenant domains in the AZURE CLOUD. AND they issue access tokens for the locally registered endpoints of apps WITHIN the tenant’s security domain, and issue id-tokens. The tokens are signed by the cloud (not the tenant) but have name scoping that indicates tenancy. One can always (locally) re-sign one’s cloud-signed token, note.</div><div><br></div><div>Presumably, I'm supposed to swap my id-token (signed by a cloud) with Google now, to get API access to some third-party Google App installed into a Google App TENANT's security domain.</div><div><br></div><div>Is the model right?</div><div><br></div><div>How real is it? 1 year, 2 year, 5 year away?</div><div><br></div><div>(I have almost no interest in whether, like IM clouds deciding to interior, whether Gmail and Hotmail decide to recognize each other - though I understand that this is probably a pre-cursor for the cloud-TENANT case).</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;"><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:home_pw@msn.com" target="_parent">peter Msn</a><br><b>Sent:</b> Friday, January 24, 2014 2:12 PM<br><b>To:</b> <a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></font></div><div><br></div><div dir="ltr"><div>Looking more at the cited openid connect case, I recognize now that we are already doing the same kind of thing as Google, apparently. That is, whereas in Google and an idtoken is apparently issued as a bearer token for OTHER audiences than the requesting party, we just happened to have the issuer of the saml bearer blob perform that role, as it nominally “accompanies” the id_token in the JSON response that retains the AS audience in our world. </div><div><br></div><div>The saml bearer token is then swapped at the MicrosoftOnline STS to get an access token for an the simple federation-secured protocols exposed by the public Office 365 APIs. As you say, this all requires that the websso client built into a pure OAUTH or openid connect authorization endpoint should request of the websso IDP that it issue a user--subject assertion with an audience OTHER than the identity of the AS (or in our case, with multiple audiences, the AS and the MicrosoftOnline audience). This also needs to have subject formats suitable for the STS (which are UPNs, and name record persistentIDs, in windows directory land).</div><div><br></div><div>Or so we thought. It turns out that the MicrosoftOnline STS is fussy about multiple audiences in the token bearer, and objects to a multiple. So, we played with the above ideas, in ways that are a bit proprietary but entirely standard in terms of using claims/libraries, so we could have multiple saml2 websso tokens coming back, one per audience.</div><div><br></div><div>This turned out to have a nice side effect, as now we can request asymmetric keyed tokens for use within the (non Office365) AS-client world. That is, the OAUTH client eventually consuming the AS’s token endpoint uses the saml bearer grant that converts the AS-audience’d SAML blob to JWTs. This was proprietary, but evidently, I can use the “salesforce” standard for that, now. Though, perhaps not …since we use asymmetric keyed bearer grants so that the fabric ends up with what is effectively a saml-blob-format self-signed user cert (in XML format, now).</div><div><br></div><div>This hybrid world is working VERY nicely. Asymmetric saml is even allowing “certs” to make a come back, now in a new blob format. We are using them for trust management between tenants of the SAAS space, rather than use directory forests and Kerberos trusts. SOME of still believe… in PKI theory for inter-domain management (when done professionally)</div><div><br></div><div>Ok that's it from me for a few months, I think.</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;"><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:home_pw@msn.com" target="_parent">peter Msn</a><br><b>Sent:</b> Thursday, January 23, 2014 8:03 PM<br><b>To:</b> <a href="mailto:ve7jtb@ve7jtb.com" target="_parent">John Bradley</a><br><b>Cc:</b> <a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></font></div><div><br></div><div dir="ltr"><div>So lets summarize.</div><div><br></div><div>Opened connect, and bearer auth from saml blobs to jwt blogs, are about millions of (X.500 style) security management domains setting up mutual trust relationship, having a cloud fabric (read X.500 chaining directory agent) enforce and enact lots of reliance policies established by namespace, and otherwise swapping id tokens for API guard-passing tokens, with the possibility that a id_token issued by IDP.X is recognized by the token swappers of another cloud, associated with IDP.Y, where X and Y have some policy agreements.</div><div><br></div><div>Ok. I get openid connect now. There are several layers of trust relationships, meta-trust relationship, and meta-meta trust (etc), that account for when one IDP relies on another for some or other purpose, as above.</div><div><br></div><div>Still think cross-certs were better suited for all this, particularly with the flexible algebra of policy matching built into X.509 v3, but that's a lost battle.</div><div><br></div><div>Thanks for the help. Reasons to at least partially adopt openid connect were made obvious. One sees the writing on the wall, now (and it is good).</div><div><br></div><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;"><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 3:30 PM<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><br></div><div dir="">The Bearer grant allows the SAML assertion to be passed directly to the token endpoint as the grant cutting out the Authorization web redirect and return of the code.<div><br></div><div>This is a optimization useful where the AS doesn't need to collect consent from the user. However the SAML IdP and the AS need to agree on how the scopes to be granted are represented in the assertion.</div><div><br></div><div>In Connect it is possible to ask for a id_token with a 3rd party as the audience. (Google is doing that with the play store) That id_token can be used in the JWT bearer grant <a href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer" target="_parent">http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer</a> to get a access token for a 3rd party API. </div><div><br></div><div>So a native app could do Connect authentication hypothetically Google then use it's refresh token to ask for a id_token with SalesForce or Microsoft as the audience and then use the id_token as the JWT grant to get a access token for SF or Azure as examples. This is more likely than Google being able to issue access tokens for those 3rd party API directly.</div><div><br></div><div>Yes you can have the app redirect to the AS and the AS do SSO Connect or SAML to a 3rd party IdP and that works but may disclose more information to the AS than is actually required.</div><div>So it is an alternate way to cross security boundaries.</div><div><br></div><div>John B.</div><div><br></div><div><div><div>On Jan 23, 2014, at 6:24 PM, Peter Williams <<a href="mailto:home_pw@msn.com" target="_parent">home_pw@msn.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote style="margin-top: 0px; margin-bottom: 0px;"><div style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', sans-serif; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;"><div><br class="Apple-interchange-newline">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="font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', sans-serif; text-transform: none; text-indent: 0px; letter-spacing: normal; padding-top: 5px; word-spacing: 0px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid; white-space: normal;"><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 style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', sans-serif; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;"><br></div><div dir="" style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 16px; line-height: normal; font-family: Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', sans-serif; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;"><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 class="Apple-interchange-newline"><blockquote style="margin-top: 0px; margin-bottom: 0px;"><div dir="ltr" style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-family: Helvetica; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal;"><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></div></div></blockquote></div><br></div></div></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>