[HN Gopher] OpenID Connect specifications published as ISO stand...
       ___________________________________________________________________
        
       OpenID Connect specifications published as ISO standards
        
       Author : mooreds
       Score  : 195 points
       Date   : 2024-11-10 16:53 UTC (6 hours ago)
        
 (HTM) web link (self-issued.info)
 (TXT) w3m dump (self-issued.info)
        
       | styczen wrote:
       | I search 2 years ago a working server and not found ;(
        
         | personality1 wrote:
         | Have you tired https://www.keycloak.org/?
        
           | dathinab wrote:
           | In my experience KeyCloak can be a very mixed bag.
           | 
           | And if you are especially unlucky might be so painful to use
           | that you could say it doesn't work.
           | 
           | But for a lot of use cases it does work well.
           | 
           | In some context it might safe you not just developer month,
           | but years (e.g. certain use cases with certification/policy
           | enforcement aspects).
           | 
           | But it also can be a story from running from one rough edge
           | into another where you project lead/manager starts doubling
           | or tripping any time estimate of stories involving Keycloak.
           | 
           | E.g. the REST API of Keycloak (for programmatic management of
           | it) is very usable but full of inconsistencies and terrible
           | badly documented (I mean there is a OpenAPI spec but it's
           | very rarely giving you satisfying answers for the meaning of
           | a listed parameter beyond a non descriptive 3 word
           | description). (It's also improving with each version.)
           | 
           | Similar multi tenancy can be a pain, depending on what
           | exactly you need. UMA can be grate or a catastrophe, again
           | depending on your specific use cases. SSO User management can
           | just fine or very painful. There is a UI for customizing the
           | auth flow, but it has a ton of subtle internal/impl. detail
           | constraints/mechanics not well documented which you have to
           | know to effectively use it so if you can't copy past someones
           | else solution or only need trivial changes this can be a huge
           | trap (looking like a easy change but being everything but
           | that)...
           | 
           | The build in mail templates work, but can get your mail
           | delivery (silently) dropped (not sure why, maybe some
           | scammers used Keycloak before).
           | 
           | The default user facing UI works but you will have to
           | customize it even if just for consistent branding and it uses
           | it's own Java specific rendering system (and consistent
           | branding here isn't just a fancy looks goal, one of the first
           | things though on scam avoidance courses for non technical
           | people is, that if it looks very different it's probably a
           | scam and you shouldn't log in).
           | 
           | I think Keycloak is somewhat of a no brainer for large teams,
           | but can be a dangerous traps for very small teams.
        
             | twobiers wrote:
             | I cannot agree more on the very mixed bag. In general,
             | Keycloak is a very solid Authorization server. There is a
             | very active community around Keycloak, and if one need an
             | authorization server, they should consider picking it. We
             | use it in an internal multi-tenant environment as a central
             | customer authentication platform.
             | 
             | BUT there's also a lot of pain in using Keycloak,
             | especially when you build on top of it. One of the great
             | things about Keycloak is, that it can be seen as an
             | extendible platform. Nearly everything is customizable.
             | However, it takes a lot of time and effort to learn the
             | programming model and especially the documentation is a
             | PITA. It has been even worse 2 years ago, but it's still a
             | lot of fiddeling around and usual I find myself in reading
             | the Keycloak source (which has a very mixed quality btw.)
             | as no documentation is available.
             | 
             | Multi tenancy is indeed also a hard topic. We heavily
             | utilize multiple realms (I think we should have hit 100
             | already) for that, but newer developments in Keycloak now
             | offer an additional model based around organizations [1].
             | 
             | One thing that bothers me personally is that the storage
             | model of keycloak does not offer zero-downtime migrations
             | and the work on refactoring it has been paused for now.
             | Since we have a solution based on Keycloak, we deploy
             | Keycloak regulary with every feature. However, the embedded
             | infinispan cache makes this hard on scale as during
             | redeployments Keycloak become unresponsive due to cache
             | leader synchronization and eventually drops some caches,
             | leading to user sessions being terminated. Fortunally
             | Keycloak finally has support for an external Infinispan
             | cache [2] and moved to protocol buffers for serialization
             | [3], which should make upgrades smoother, and grounds the
             | road to zero-downtime deployments.
             | 
             | After all this, let me emphasize that for most of it the
             | Keycloak team is aware and is working hard in moving
             | forward. I started using Keycloak with Version 11 and a lot
             | has changed for the better.
             | 
             | > I think Keycloak is somewhat of a no brainer for large
             | teams, but can be a dangerous traps for very small teams.
             | 
             | I would not agree on that. You don't necessarily need a
             | large team for operating Keycloak and smaller teams are
             | probably not that big of an issue. At least not for
             | operating Keycloak. What I feel to be more a problem is,
             | that many (at least of our) clients are not understanding
             | OAuth 2.0 and OIDC well, and therefore puts a larger burdon
             | on support work. Also there must be at least someone very
             | knowledgable of Keycloak to give guidance to the rest of
             | the team, but in general I would not say it's dangerous. We
             | have even a team operating their own keycloak and using our
             | keycloak to perform OIDC federation (don't ask me why tho,
             | I never understood it).
             | 
             | [1] https://www.keycloak.org/2024/06/announcement-keycloak-
             | organ... [2]
             | https://github.com/keycloak/keycloak/issues/28745 [3] https
             | ://www.keycloak.org/docs/latest/release_notes/index.htm...
        
         | uj6re wrote:
         | open source: keycloak connect2id dex gluu
         | 
         | closed source self hosted: adfs
         | 
         | hosted: okta (auth0) google microsoft github amazon
         | 
         | these are just the ones that were viable 2 years ago
        
           | orphea wrote:
           | also open source: zitadel
        
           | orra wrote:
           | Thanks, although connect2id doesn't look open source.
        
           | vemgar wrote:
           | also open source: Authentik
        
           | mooreds wrote:
           | Another closed source option, which can be self-hosted or
           | used as a SaaS: FusionAuth (my employer). It also has a full
           | featured plan which is free if you self host and is available
           | via docker, etc.
        
         | mrweasel wrote:
         | We run Apereo CAS pretty successfully. Originally to use the
         | CAS protocol, but now that CAS (the protocol) has been
         | deprecated, we're slowly migrating to OIDC. One sort of weird
         | note about Apereo CAS, OpenID Connect can return data in two
         | format, nested and flat. CAS is the only server I've ever
         | worked with, that defaults to nested. Almost no clients
         | supports this, but the server can be reconfigured to use flat.
         | 
         | KeyCloak is also very good, but I'd run is as a container due
         | to the quick release/update cycle. If I had to do our
         | infrastructure over, I'd probably go for KeyCloak, just because
         | it's the most used.
        
           | mooreds wrote:
           | Hmmm. Here's details about using CAS as an OpenID Connect
           | provider:
           | https://apereo.github.io/cas/7.0.x/authentication/OIDC-
           | Authe...
           | 
           | Looks like it doesn't support multiple issuers: " CAS
           | primarily supports a single issuer per deployment/host." Have
           | you run into any issues with that?
           | 
           | It also looks like it supports a number of optional
           | standards: DPoP, JARM, PAR. Have you seen use cases for
           | these?
        
       | paxys wrote:
       | Sweet, one more standard for developers to ignore.
        
       | simonw wrote:
       | It took me an embarassingly long time (given how keenly involved
       | I was in OpenID stuff ~17 years ago
       | https://simonwillison.net/search/?tag=openid&year=2007) to
       | understand that OpenID Connect is almost unrelated to the
       | original idea of OpenID where your identity is a URL and you can
       | prove that you own that URL.
       | 
       | OpenID Connect is effectively an evolution of OAuth.
        
         | mrweasel wrote:
         | My understand is that OpenID Connect is build on top of OAuth2,
         | sort of a specialization.
        
           | jcmfernandes wrote:
           | Correct. OAuth is for delegated authorization. OpenID Connect
           | for authentication.
        
             | mooreds wrote:
             | > OAuth is for delegated authorization.
             | 
             | Have you ever seen OAuth used alone? I'm looking for
             | examples of this and they seem to be few and far between.
        
               | anon84873628 wrote:
               | What do you mean? What is an example of it not being used
               | alone?
        
               | mooreds wrote:
               | I mean it is usually paired with an id token, an
               | identifier like an email address is provided, or the
               | access token has a sub claim that is tied back to the
               | user.
               | 
               | So it is not pure authorization, but both authentication
               | and authorization.
               | 
               | Pure authorization would be like a car key, with no
               | identity mixed in.
        
               | jcmfernandes wrote:
               | There are LOTS of them. Anything that allows you to link
               | your Google/Facebook/etc. account to another system, so
               | that system can perform actions on your
               | Google/Facebook/etc. account on your behalf.
               | 
               | Examples: Slack (e.g., notify you of events on your
               | calendar, create a GMeets meeting), services like
               | cal.com, whatsapp (store backups on your Google Drive).
        
               | hirsin wrote:
               | It's rare in my experience. We don't support OIDC, so
               | technically it's standalone oauth. In reality there's of
               | course a user identity in the mix used to authorize the
               | resulting access tokens.
               | 
               | Even server to server calls, ie daemons, service
               | principals, what have you, still rely on a client
               | identity.
               | 
               | I think the closest to true agentless access I've seen
               | widely used are SAS for Azure Storage and of course
               | deploy keys in GitHub, which we're building off ramps
               | for. Agentless authz just is not a good idea
        
         | alasr wrote:
         | You may already know this, I'm writing it as a note for my
         | future self.
         | 
         | OpenID Connect (OIDC) is mostly concerned with
         | _authentication_. On the other hand, OAuth (or, to be more
         | specific, OAuth v2.0) is concerned with _authorization_.
         | 
         | >> OpenID Connect is effectively an evolution of OAuth.
         | 
         | In my opinion, OpenID Connect is actually evolution of OpenID -
         | in its vision/spirit:
         | 
         | - OIDC, like OpenID, primarily focuses on users' identity and
         | authentication;
         | 
         | - OIDC, unlike OpenID, didn't (re)invent new authentication
         | workflows, which were significantly different in their own
         | ways. Instead, it built authentication workflows on top of
         | existing OAuth spec (which was being (ab)used for
         | authentication in some places which, unfortunately, is still
         | the case) to achieve its main objective (i.e. authentication).
         | 
         | ---
         | 
         | Edit: rephrased to better communicate my thoughts (still not
         | perfect; but, as the saying goes, perfect is the enemy of the
         | good so I stop here).
        
           | wtallis wrote:
           | > OIDC, unlike OpenID, didn't (re)invent new authentication
           | workflows, which were significantly different in their own
           | ways. Instead, it built authentication workflows on top of
           | existing OAuth spec
           | 
           | Didn't OpenID predate OAuth? What should OpenID have built
           | upon?
        
             | alasr wrote:
             | >> Didn't OpenID predate OAuth? What should OpenID have
             | built upon?
             | 
             | Yes, you're right about "OpenID predate OAuth" part.
             | 
             | However, from my point-of-view, it seems the main source of
             | confusion here is the double sense of the word _OpenID_ : I
             | think, there're at least two distinct senses associated
             | with the word OpenID:
             | 
             | - First, the original OpenID authentication protocol
             | developed around 2005 which communicates the idea of a
             | _decentralized_ online digital identity where one way a
             | user can asserts their digital identity is via a URL _under
             | their control_.
             | 
             | - Second, OpenID used as part of the compound noun in
             | "OpenID Connect" (which Wikipedia says "third generation of
             | OpenID technology", published in 2014[1]) which implements
             | the user identity and their authentication via workflows
             | built on top of OAuth2 spec.
             | 
             | It is in this second sense what I meant by "OIDC ... built
             | on top of existing OAuth spec ... to achieve its main
             | objective (i.e. authentication)."
             | 
             | Note:
             | 
             | By the way, you may have already noted, I used OIDC (which
             | stands or OpenId Connect), not just OpenId (in the first
             | sense of the word OpenId) in my original post. I hope it
             | helps.
             | 
             | An aside, looking at all the comments about "OpenId" and
             | "OpenId Connect", I'm reminded of the following post: Two
             | Hard Things[2]
             | 
             | ---
             | 
             | [1] -
             | https://en.wikipedia.org/wiki/Openid#OpenID_Connect_(OIDC)
             | 
             | [2] - https://martinfowler.com/bliki/TwoHardThings.html
        
           | simonw wrote:
           | My problem with it being called OpenID Connect is that, in my
           | head, an OpenID is a noun which means "a URL that you can use
           | as your identity and prove that you own".
           | 
           | That definition doesn't work for OpenID Connect. Is OpenID a
           | noun any more? I don't think it is.
        
             | clhodapp wrote:
             | OpenID Connect can _totally_ work that way if used with
             | WebFinger for endpoint discovery, and occasionally this is
             | implemented (though many websites do not).
        
         | antod wrote:
         | Your talk at webstock back in 2008 is what originally got me
         | interested in OpenID.
        
         | mooreds wrote:
         | Yeah, it's a profile on top of OAuth, which leverages aspects
         | (the authorization code grant, tokens) but adds some other
         | functionality (another token with authentication information
         | and some defined claims). I'm not aware of any other profiles
         | with anywhere near the uptake of OIDC.
         | 
         | There are a few folks out there doing pure OAuth, but much of
         | the time it is paired with OIDC. It's pretty darn common to
         | want someone to be authenticated the same time they are
         | authorized, especially in a first party context.
         | 
         | I wrote more on OIDC here:
         | https://fusionauth.io/articles/identity-basics/what-is-oidc
        
         | dathinab wrote:
         | Also interesting is that OAuth2 is a bit too flexible in how
         | you can put things together and OIDC provides a lot of good
         | practice about that how.
         | 
         | So even systems where OIDC compliance is a non goal often are
         | partially OIDC compliant, I mean there really is no reason to
         | reinvent the wheel if part of the OIDC standard already provide
         | all you need.
        
           | clhodapp wrote:
           | OAuth 2.1 tightens it up a bit.
           | 
           | I don't think very many people know that OAuth 2.1 exists,
           | though.
        
         | lifeisstillgood wrote:
         | Is it a question of how bad OAuth 2.0 is then?
         | 
         | """ David Harris, author of the email client Pegasus Mail, has
         | criticised OAuth 2.0 as "an absolute dog's breakfast", """
         | https://en.m.wikipedia.org/wiki/OAuth
         | 
         | I keep on trying and failing to implement / understand OAuth 2
         | and honestly feel I need to go right back to square one to grok
         | the "modern" auth/auth stack
        
           | 9dev wrote:
           | It's funny, I'm the opposite. I love OAuth for what it does,
           | that is, federate permission to do stuff across applications.
           | It makes a lot of cool integration use cases possible across
           | software vendor ecosystems, and has single-handedly made
           | interoperability between wildly different applications
           | possible in the first place.
           | 
           | I'd say it definitely helps to implement an authorisation
           | server from scratch once, and you'll realise it actually
           | isn't a complex protocol at all! Most of the confusion stems
           | from the many different flows there were at the beginning,
           | but most of it has been smoothened out by now.
        
           | __mattya wrote:
           | OIDC is what fixes the "dog breakfast" criticism. With OIDC
           | you (in theory) don't have to write custom modules per
           | provider anymore.
        
             | kodama-lens wrote:
             | It would fix a lot of the provider specific aspects of
             | OAuth2, if the spec would be more strict on some claim
             | (attribute) names on the jwt ID token. Some provide groups,
             | some don't. Some call it roles or direct_groups. Some
             | include prefered_username, some don't. Some include full
             | name, some don't and don't get me started on name and
             | first_name.
             | 
             | If you implement OIDC you must certainly provide a
             | configurable mapping system for source claim name to your
             | internel representation of a user object.
        
         | ForHackernews wrote:
         | The naming is a complete nightmare.
         | 
         | OpenID Connect is an extension to OAuth2 (RFC 6749) that adds
         | an authentication layer (to identify a user) on top of the
         | OAuth2 authorization framework (that grants permissions)
         | 
         | Earlier versions of OAuth (1.0 and 1.0a) and OpenID (1 and 2)
         | are unrelated, incompatible protocols that share similar names
         | but are largely irrelevant in 2024.
         | 
         | Google with care.
        
       | nick238 wrote:
       | Standards are nice, but the large standards organizations like
       | ISO annoyingly charge a bit to view them. I suppose this is
       | because some businesses/industries require "real" standards by
       | those orgs rather than the IETF or other dirty open-source hippie
       | collectives.
        
         | pyuser583 wrote:
         | They claim it's to provide access and funding to undeveloped
         | parts of the world.
        
           | lysace wrote:
           | :-)
        
           | urbandw311er wrote:
           | Nice one
        
         | pclmulqdq wrote:
         | Most standards are low priced enough that they are sold at a
         | loss. If you would prefer to donate to ISO (or the IEEE for
         | another example) instead, that would help allay the cost of
         | writing a standard.
        
       | lysace wrote:
       | Pay-to-read standards like those of the ISO actively hinder human
       | progress. Please don't encourage this behaviour.
        
         | penguin_booze wrote:
         | With C++, the latest draft of the standard is made available
         | for free [0]. My understanding is that the final draft and the
         | official standard are more or less same w.r.t. their material
         | content. I imagine the draft standard for OIDC is also
         | available somewhere.
         | 
         | [0]
         | https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
        
           | lysace wrote:
           | > My understanding is that the final draft and the official
           | standard are more or less same w.r.t. their material content.
           | 
           | Details matter. So not so open after all?
        
       | bborud wrote:
       | No aspect of this is good for anyone. First, standards you have
       | to pay to obtain are a really, really bad thing. Second, I wish
       | more effort would go into designing standards and implementations
       | that aren't such an endless time sink when you need them.
        
         | woodruffw wrote:
         | I agree about ISO, but I don't think there's a meaningful "toll
         | gate" in this case: the standards are already free and public,
         | this seems to just assign them identities in the ISO's
         | standardization namespace.
         | 
         | (I'm at a loss to explain what benefit comes from being
         | assigned an ISO standard versus putting a HTML document on the
         | Internet.)
        
           | mooreds wrote:
           | > (I'm at a loss to explain what benefit comes from being
           | assigned an ISO standard versus putting a HTML document on
           | the Internet.)
           | 
           | From the article:
           | 
           | "[ISO certification] should foster even broader adoption of
           | OpenID Connect by enabling deployments in jurisdictions
           | around the world that have legal requirements to use
           | specifications from standards bodies recognized by
           | international treaties, of which ISO is one."
        
             | woodruffw wrote:
             | The point was that countries _clearly_ recognize standards
             | that aren 't bound to an ISO (or other international
             | standards) process, given that every country in the world
             | uses TCP, HTTP, and HTML.
             | 
             | (Unless we're now considering the IETF/W3C an international
             | standards body? I can't find a good list of these
             | anywhere.)
        
               | mooreds wrote:
               | That's fair. And this type of standardization is far
               | enough outside my wheelhouse that I don't know how to
               | judge Mike's comments. He's pretty deep in that space, so
               | I take it at face value. I don't think he'd have pushed
               | this effort without there being value.
               | 
               | Looked on the OpenID mailing list site[0] and didn't find
               | any discussion, so can't offer any other insight. I
               | suppose you could contact Mike[1] and ask why it is such
               | a big deal)?
               | 
               | > Unless we're now considering the IETF/W3C an
               | international standards body?
               | 
               | Most of what I know about standards bodies I learned from
               | Heather Flanagan, who is/was active in a lot of these and
               | did a great presentation at Identiverse in 2022[2] about
               | this very topic.
               | 
               | 0: https://lists.openid.net/mailman/listinfo
               | 
               | 1: https://self-issued.consulting/contact-me
               | 
               | 2: https://www.youtube.com/watch?v=YBP8ffezycY
        
               | patmorgan23 wrote:
               | From wikipedia:
               | 
               | >The World Wide Web Consortium (W3C) is the main
               | international standards organization for the World Wide
               | Web.
               | 
               | >The Internet Engineering Task Force (IETF) is a
               | standards organization for the Internet and is
               | responsible for the technical standards that make up the
               | Internet protocol suite (TCP/IP).
               | 
               | I would also add IEEE to this list. I think it's pretty
               | clear these groups are international standards
               | organizations, it think it's pretty odd that OpenID
               | Connect wasn't circulated as an RFC and they went the ISO
               | route.
        
               | pclmulqdq wrote:
               | Many standards are ISO standards as well as a standard
               | from some other body. I have some involvement with the
               | floating point standard, and that is mostly an IEEE
               | standard, but the chair of the committee does ISO
               | standardization as well for each revision.
        
           | mananaysiempre wrote:
           | > I don't think there's a meaningful "toll gate" in this
           | case: the standards are already free and public
           | 
           | See Adobe and PDF: PDF 1.7 was available gratis from Adobe
           | and also ("technically identical to") an ISO standard. At the
           | time, people expressed concerns about ISO's paywalls and
           | Adobe reassured them there was an agreement to ensure that
           | wouldn't happen. Indeed it did not... until PDF 2.0 came
           | along, developed at the ISO, and completely paywalled.
           | 
           | I seem to remember (but don't quote me on that) that AVIF and
           | JPEG XL standards were at one point downloadable free of
           | charge. In any case, they aren't today.
        
             | whenc wrote:
             | This has now been remedied:
             | 
             | https://pdfa.org/sponsored-standards/
        
           | noirscape wrote:
           | Any sort of government or similarly "official" organization
           | loves to refer to ISO standard XXXX instead of writing out a
           | summary of the standard when they document things.
           | 
           | Sometimes you see the same thing with organizations referring
           | to web RFCs. It's likely because of a general culture of
           | "don't try to invent new things if you already have a
           | reference for it", although it doesn't really tend to make
           | those documents readable.
        
         | seb1204 wrote:
         | Why does the internet not make this stuff a RFC? Email and TCP
         | are RFCs so are other critical aspects and global companies use
         | the all the time.
        
       | revskill wrote:
       | ISO means It's so overcomplicated i think.
        
         | jcmfernandes wrote:
         | Since OIDC is a layer on top of OAuth 2, it inherits its
         | complexity. OAuth 2.1 (currently draft) will help bring some
         | sanity. GNAP - https://oauth.net/gnap/ - will, one day, tie
         | everything.
        
           | mooreds wrote:
           | GNAP was just codified to be an RFC: https://www.rfc-
           | editor.org/rfc/rfc9635.html
           | 
           | When I looked at it a few years ago[0] it seemed like a
           | modernization of OAuth (which still uses form posts(?!?)).
           | But I'm worried about uptake, myself. Haven't had a single
           | client request it or bring it up.
           | 
           | 0: https://fusionauth.io/blog/gnap-next-gen-oauth
        
       | benterix wrote:
       | Great. So now we have to pay to read them.
        
         | mooreds wrote:
         | I don't think so. I think they just have the imprimatur of the
         | ISO standards body now. I don't see
         | https://openid.net/specs/openid-connect-core-1_0.html going
         | behind a paywall.
        
       | surfingdino wrote:
       | Making it an ISO publication makes it an ass cover for
       | procurement. Nobody got fired for demanding compliance with a
       | pile of ISO standards after all.
        
       | spapas82 wrote:
       | OpenID connect is a rather simple protocol. I was able to
       | understand most of it in about a day by reading the specs
       | (https://openid.net/specs/openid-connect-core-1_0.html). For
       | anybody that's interested and doesn't want to read these specs,
       | I've written a comprehensive tutorial on how to implement a
       | client for OpenID using simple HTTP requests
       | (https://spapas.github.io/2023/11/29/openid-connect-tutorial/).
       | 
       | It's using python to do the work but it should be straight
       | forward to implement it in anything you want. Most of the complex
       | stuff is related to decoding and checking the JWT tokens.
       | 
       | I'm using exactly this hand written client on a production
       | project to authenticate with keycloak for like a year and
       | everything's working perfectly!
       | 
       | PS: I know that there are _way_ too many ads to my site.
       | Unfortunately I haven 't found the time to properly configure
       | google ads and haven't found anything better :( Use an ad-blocker
       | to read it.
        
         | mmcnl wrote:
         | Very interesting and good write-up.
         | 
         | PS. Be cautious with using subjective words like "simple". It
         | can be really off-putting as a reader if you think something is
         | difficult and the author claims it's simple.
        
           | lurking_swe wrote:
           | everything is relative. I believe it's "simple" compared to
           | other standards like SAML.
           | 
           | I agree it can be a little intimidating for a novice in the
           | space!
        
           | spapas82 wrote:
           | Probably I should have said "simple compared to oauth" :)
        
       | koito17 wrote:
       | I fear this will be as adopted as PDF/2.0, the first non-free
       | (and ISO) specification of the PDF format.
       | 
       | Hopefully the draft versions are freely available somewhere and
       | closely resemble the final product^W specification.
        
         | alasr wrote:
         | Just found the following on PDF 2.0 (announced on April 5,
         | 2023): https://pdfa.org/announcing-no-cost-access-to-
         | iso-32000-2-pd...
         | 
         | Still, I agree with your main point: let's hope future OIDC ISO
         | spec(s) is/are still freely available in some form.
        
       | anilakar wrote:
       | Great. Now I need to pay for a huge pile of toilet paper to prove
       | compliance.
        
       | sundarurfriend wrote:
       | The link through to PAS says:
       | 
       | > Publicly Available Specifications have a maximum life of six
       | years, after which they can be transformed into an International
       | Standard or withdrawn.
       | 
       | So is the plan to transform this into a standard after that
       | period? Was a PAS application chosen because (it sounds like) it
       | goes through the standards body quicker? So this gives an
       | intermediate ISO seal of validation until this becomes a full
       | International Standard?
        
       | sunshine-o wrote:
       | Is there an independent OIDC issuer (outside of Google, MS or
       | Apple) left one can create an account on?
       | 
       | I wanted to open an account on Tailscale without using my Github
       | account the other day but couldn't.
       | 
       | I believe openid.net and Ubuntu One were providing this service a
       | long time ago but they discontinued it.
        
       ___________________________________________________________________
       (page generated 2024-11-10 23:00 UTC)