is OpenID Connect on the roadmap?

[Peter Williams]

That's not a helpful, from either of you - given the formal position of incommon.  InCommon and Shib must be seen as VERY distinct political entities these days, though. 

I'm not happy with the openid connect concept and policy line that I've seen so far. But, I'm NOT going into the multi-year evaluation with a biased position (as a developer architecting extension sand deployment points for private cloud software sets). 

I don't expect the next 5 years of websso to bear much relation to the previous 5, since we have gone from a world of 50 US universities to a million Office 365 idps (and another million Google Apps IDPs) in that timeframe. In consultancies I cannot say much about (mostly because the firms were doing such a BAD job of DELIVERY), I expect some major names to be offering enterprise versions of multi-tenant IDPs, too - mostly targeting SP communities wanting pseudo national-id confirmation/assurance levels. It will be fun to see them compete with the likes of the pending Azure AD IDP work from Microsoft (and its chaining IDP concept, in particular). The modernized X.500 directory-style initiative  (now stripped of the last vestiges of ASN.1 and DNs.., in favor of JSON and URIs) is free from having to meet US govt standards that have little market-based economic drivers. It will be interesting to see how the great soviet-style 5-year plans of centralized NIST planning compete against the free market.

Oh, how easy it is to fall into propagandizing and demonizing. Shame on me, Peter. Remember Peter, you actually respect NIST  - on the basis of record. And record is what counts.

Now I have NO DOUBT (knowing the DEV policy line at Microsoft) that if we were to see an openid connect like deliverable from that firm, it will be multi-protocol - and the libraries for RPs working with many different bit formats and protocol exchanges (all of which have largely the same function). In just the same way that they took the humble SAML assertion so well developed here and built it also into the ws-fedp the multi-agent chaining STS concept (going beyond SAML2 authnReq protocol's more limited concept set of IDP, proxy IDP, SP, SP affiliation), so I **EXPECT** them to "open up" openid connect. It would no doubt be called "websso connect" or something - to lessen the harangues to normal pitch.

Yesterday, I made the n million tenants of the Office365 program, each with an ws-fedp IDP, talk to our SP affiliation network. This augments what we did with Google last year, enabling their openid protocol to let a million Google APPs tenants also send assertions (that the Azure cloud converts to ws-fedp and SAML2 assertions, for us). I can find no reason to discriminate against customer sites those who take these particular IDP deployment routes. In all cases, and just as with Paul's IDP farm, an external party's assertion will only ever land on an STS representing the SP affiliation - that re-asserts to the true site(s) leveraging identity claims. Given this architecture, when I remember I call the SP affiliation's ACS endpoint the "SP" (and the "true" sites with app functions based on identity claims the RPs).

Let me finish by banging the pure SAML2 drum. Has anyone tried interworking the modern Shib SP with the SAML2 IDP from the Azure AD multi-tenant system? I note that the tenants there have SAML2 IDP metadata - in addition to ws-fedp service descriptors. It would be entirely consistent with ADFS having SAML2 SP capabilities that the Azure AD directory IDPs would SAML2 (and AuthnReq support ). This allows RP sites to continue to leverage Kerberos tokens, as claims are translated from SAML2 assertions to the token types used by the TCB of the OS.

Hope this helps - given its a developer speaking - and one is not particularly to any particular camp. The tone is supposed to say: the world is changing, and the space for religious tech arguments and the doctrine separation of equals is fast diminishing. The world of websso is going multi-cultural, and Im not standing in the way of that.


________________________________________
From: dev-bounces at shibboleth.net [dev-bounces at shibboleth.net] On Behalf Of Paul Hethmon [paul.hethmon at clareitysecurity.com]
Sent: Thursday, November 01, 2012 6:13 AM
To: Shib Dev
Subject: Re: is OpenID Connect on the roadmap?

Rod,

Thanks for sharing that. I've not run across it before, but it is so true.

cheers,

Paul


On 11/1/12 8:48 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>Sort of relevant:
>
>http://www.joelonsoftware.com/articles/fog0000000069.html
>
>"It didn't work well last time, so we'll start again from the ground up
>and this time it's bound to take off".
>
>Even if it isn't relevant to the topic, it has to be relevant to any
>mailing list with "dev" in the title.  Anyone who has developer
>pretensions need to read this and the mythical man month at least once a
>decade.
>
>> -----Original Message-----
>> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net] On
>>Behalf Of Tom Scavo
>> Sent: 31 October 2012 23:50
>> To: Shibboleth Developers
>> Subject: is OpenID Connect on the roadmap?
>>
>> I realize the Shib dev team is sorta rebuilding right now but I thought
>>I'd bring this up anyway. Are
>> there plans to add OpenID Connect to the list of protocols supported by
>>the IdP? It would be much
>> easier to introduce OpenID Connect in the InCommon Federation if the
>>IdP supported it natively.
>>
>> A possible response might be: why implement OpenID Connect in the IdP
>>first (if Shib supports it at
>> all)? As is usually the case, it's a chicken-and-egg problem that kinda
>>depends on how you look at it.
>> My thought (today) is that if OpenID Connect succeeds, it will succeed
>>at internal SSO before external
>> SSO (which is exactly what we've seen happen with SAML). But I don't
>>really want to debate priorities,
>> I'm more interested in your thoughts regarding OpenID Connect as a
>>supported protocol in Shibboleth.
>>
>> Thoughts?
>>
>> Thanks,
>> Tom
>> --
>> To unsubscribe from this list send an email to
>>dev-unsubscribe at shibboleth.net
>
>--
>To unsubscribe from this list send an email to
>dev-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net