I’m flying on four different airlines over the next week. I’m going to try to document my experience on each of them so I can see who I should be loyal to.
LOL, who am I kidding? I’m not loyal to companies.
{
"type": "entry",
"published": "2019-12-13T03:33:12+00:00",
"url": "https://twitter.com/jackyalcine/status/1205329796588298240",
"content": {
"text": "I\u2019m flying on four different airlines over the next week. I\u2019m going to try to document my experience on each of them so I can see who I should be loyal to.\n\nLOL, who am I kidding? I\u2019m not loyal to companies."
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"_id": "6944360",
"_source": "2773"
}
It’s because of rich people, lol. https://t.co/YJq217Lufn
Warren's wealth tax will generate $1 trillion less than she claims, study finds cbsn.ws/2rHKuAF
{
"type": "entry",
"published": "2019-12-13T03:32:15+00:00",
"url": "https://twitter.com/jackyalcine/status/1205329559517847553",
"quotation-of": "https://twitter.com/CBSNews/status/1205210612667686912",
"content": {
"text": "It\u2019s because of rich people, lol. https://t.co/YJq217Lufn"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"refs": {
"https://twitter.com/CBSNews/status/1205210612667686912": {
"type": "entry",
"published": "2019-12-12T19:39:36+00:00",
"url": "https://twitter.com/CBSNews/status/1205210612667686912",
"photo": [
"https://pbs.twimg.com/media/ELnEqkEXUAYLDS7.jpg"
],
"content": {
"text": "Warren's wealth tax will generate $1 trillion less than she claims, study finds cbsn.ws/2rHKuAF",
"html": "Warren's wealth tax will generate $1 trillion less than she claims, study finds <a href=\"https://cbsn.ws/2rHKuAF\">cbsn.ws/2rHKuAF</a>"
},
"author": {
"type": "card",
"name": "CBS News",
"url": "https://twitter.com/CBSNews",
"photo": "https://pbs.twimg.com/profile_images/645966750941626368/d0Q4voGK.jpg"
},
"post-type": "photo"
}
},
"_id": "6944361",
"_source": "2773"
}
🗣YOU NIGGAS ARE DUMB!
twitter.com/jackyalcine/st…
{
"type": "entry",
"published": "2019-12-13T03:31:28+00:00",
"url": "https://twitter.com/jackyalcine/status/1205329363362697217",
"quotation-of": "https://twitter.com/pistolsnpoetry/status/1205328249632575488",
"content": {
"text": "fake news y'all"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"refs": {
"https://twitter.com/pistolsnpoetry/status/1205328249632575488": {
"type": "entry",
"published": "2019-12-13T03:27:03+00:00",
"url": "https://twitter.com/pistolsnpoetry/status/1205328249632575488",
"content": {
"text": "\ud83d\udde3YOU NIGGAS ARE DUMB!\ntwitter.com/jackyalcine/st\u2026",
"html": "\ud83d\udde3YOU NIGGAS ARE DUMB!\n<a href=\"https://twitter.com/jackyalcine/status/1205328126214955010\">twitter.com/jackyalcine/st\u2026</a>"
},
"author": {
"type": "card",
"name": "lil lilith",
"url": "https://twitter.com/pistolsnpoetry",
"photo": "https://pbs.twimg.com/profile_images/1199126364240121856/Mesmdxq5.jpg"
},
"post-type": "note"
}
},
"_id": "6944362",
"_source": "2773"
}
That’s actually crazy. https://t.co/NVzTHq3ziI
BREAKING: Labour Leader Jeremy Corbyn is to resign and will not lead the party into a future general election.
{
"type": "entry",
"published": "2019-12-13T03:30:34+00:00",
"url": "https://twitter.com/jackyalcine/status/1205329136107106310",
"quotation-of": "https://twitter.com/britainelects/status/1205327926520090626",
"content": {
"text": "That\u2019s actually crazy. https://t.co/NVzTHq3ziI"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"refs": {
"https://twitter.com/britainelects/status/1205327926520090626": {
"type": "entry",
"published": "2019-12-13T03:25:46+00:00",
"url": "https://twitter.com/britainelects/status/1205327926520090626",
"photo": [
"https://pbs.twimg.com/media/ELovNfMWsAE8KeC.jpg"
],
"content": {
"text": "BREAKING: Labour Leader Jeremy Corbyn is to resign and will not lead the party into a future general election."
},
"author": {
"type": "card",
"name": "Britain Elects",
"url": "https://twitter.com/britainelects",
"photo": "https://pbs.twimg.com/profile_images/1196617774816276480/6MaO8-vg.jpg"
},
"post-type": "photo"
}
},
"_id": "6944364",
"_source": "2773"
}
Listening to @Domi_Labs pitch at @ssi_incubator demo evening in San Francisco. I certainly agree there is friction to be eliminated in the appartment rental process, and fraud to be cut down. And #privacy can be improved significantly. #SSI might very well the tech to do it.
{
"type": "entry",
"published": "2019-12-13T03:20:21+00:00",
"url": "https://twitter.com/Johannes_Ernst/status/1205326565833232386",
"content": {
"text": "Listening to @Domi_Labs pitch at @ssi_incubator demo evening in San Francisco. I certainly agree there is friction to be eliminated in the appartment rental process, and fraud to be cut down. And #privacy can be improved significantly. #SSI might very well the tech to do it.",
"html": "Listening to <a href=\"https://twitter.com/Domi_Labs\">@Domi_Labs</a> pitch at <a href=\"https://twitter.com/ssi_incubator\">@ssi_incubator</a> demo evening in San Francisco. I certainly agree there is friction to be eliminated in the appartment rental process, and fraud to be cut down. And <a href=\"https://twitter.com/search?q=%23privacy\">#privacy</a> can be improved significantly. <a href=\"https://twitter.com/search?q=%23SSI\">#SSI</a> might very well the tech to do it."
},
"author": {
"type": "card",
"name": "Johannes Ernst",
"url": "https://twitter.com/Johannes_Ernst",
"photo": "https://pbs.twimg.com/profile_images/462335209015238656/ie0cRjdx.jpeg"
},
"post-type": "note",
"_id": "6944034",
"_source": "2773"
}
Heartbroken by the news out of the UK. No chance the exit polls are wildly wrong eh?
{
"type": "entry",
"published": "2019-12-13T02:21:36+00:00",
"url": "https://twitter.com/anomalily/status/1205311777916899329",
"content": {
"text": "Heartbroken by the news out of the UK. No chance the exit polls are wildly wrong eh?"
},
"author": {
"type": "card",
"name": "Lillian Karabaic",
"url": "https://twitter.com/anomalily",
"photo": "https://pbs.twimg.com/profile_images/1123802400731664385/dsHQG1nZ.jpg"
},
"post-type": "note",
"_id": "6942904",
"_source": "2773"
}
{
"type": "entry",
"published": "2019-12-13T02:17:21+00:00",
"url": "https://twitter.com/aaronpk/status/1205310710818852864",
"content": {
"text": "It's time for OAuth 2.1\n\naaronparecki.com/2019/12/12/21/\u2026",
"html": "It's time for OAuth 2.1\n\n<a href=\"https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1\">aaronparecki.com/2019/12/12/21/\u2026</a>"
},
"author": {
"type": "card",
"name": "Aaron Parecki",
"url": "https://twitter.com/aaronpk",
"photo": "https://pbs.twimg.com/profile_images/1103120425846857728/X3d0a2Tr.png"
},
"post-type": "note",
"_id": "6942532",
"_source": "2773"
}
{
"type": "entry",
"published": "2019-12-12T18:10:22-08:00",
"url": "https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1",
"category": [
"oauth",
"oauth2",
"oauth21"
],
"name": "It's Time for OAuth 2.1",
"content": {
"text": "Trying to understand OAuth often feels like being trapped inside a maze of specs, trying to find your way out, before you can finally do what you actually set out to do: build your application.\n\n\n\nWhile this can be incredibly frustrating, it\u2019s no accident that OAuth is actually made up of many different RFCs, building upon each other and adding features in different ways.\n\nIn fact, the \u201ccore\u201d OAuth spec, RFC 6749, isn\u2019t even called a specification, it\u2019s technically a \u201cframework\u201d you can use to build specifications from. Part of the reason for this is because it leaves a lot of things optional, and requires that an implementer makes decisions about things like which grant types to support, whether or not refresh tokens are one-time use, and even whether access tokens should be Bearer tokens or use some sort of signed token mechanism.\n\nThis has often been quoted as the biggest failure of OAuth, but is also a large part of the reason OAuth has been successfully deployed at the largest companies at scale over the last 10 years.\n\nOAuth has been patched and extended a lot in the last decade of experience deploying systems using it. It\u2019s been extended in ways the original authors could never even see coming. Keep in mind that when OAuth 2.0 was published in 2012, the iPhone 5 was brand new, the latest browser from Microsoft was Internet Explorer 9, single-page apps were called \u201cAJAX apps\u201d, and CORS was not yet an established W3C standard.\n\nSince 2012, the web and mobile landscape has changed dramatically. More people access the internet from mobile devices than desktop devices, single-page apps are an extremely common way of creating web apps, and countless password database breaches have time and again demonstrated that storing passwords is dangerous.\n\nThe Evolving OAuth 2.0 Landscape\n\nTo address this changing landscape, the OAuth community has patched and added to the OAuth spec over the years. The OAuth core spec (RFC 6749) defines four grant types: Authorization Code, Implicit, Password, and Client Credentials. It used to be the case that the Implicit grant was recommended for both JavaScript apps as well as native apps.\n\n\n\nIt became apparent that a better solution was needed for mobile apps, so PKCE (RFC 7636) was created to provide a way to use the Authorization Code flow without a client secret.\n\n\n\nLater, \u201cOAuth 2.0 for Native Apps\u201d (RFC 8252) was published, which recommends that native apps use the Authorization Code flow with the PKCE extension.\n\n\n\nA new class of device arose along with a need to use OAuth with them: devices that have no browser or lack a keyboard, such as an Apple TV or YouTube streaming video encoder. An entirely new OAuth grant was created to address this, called the Device Grant, published as RFC 8626.\n\n\n\nThere are even more patches currently in the works. I am writing a draft for best practices for single-page apps, and the latest Security Best Current Practice (BCP) is currently in the final call. The single-page apps draft recommends using PKCE with JavaScript apps and says you should no longer use the Implicit flow. The Security BCP effectively deprecates the Implicit flow as well as the Password grant out of OAuth entirely, and further recommends using PKCE even for web server apps.\n\nSo what started out as a list of four grant types has had things added and removed, and now looks more like this.\n\n\n\nWhich, if you look closely, actually ends up distilling down to this:\n\n\n\nSo what we\u2019ve effectively done is taken the core OAuth RFC, added and removed things, and turned it into an entirely different set of recommendations. The problem is that it requires reading far too many RFCs to understand this landscape.\n\nIf you want to implement a secure OAuth solution today, it requires reading: RFC 6749 (OAuth 2.0 Core), RFC 6750 (Bearer Tokens), RFC 6819 (Threat Model and Security Considerations), RFC 8252 (OAuth for Native Apps), RFC 8628 (Device Grant), OAuth for Browser-Based Apps, OAuth 2.0 Security Best Current Practice, RFC 7009 (Token Revocation), RFC 8414 (Authorization Server Metadata), and if you\u2019re also implementing an OAuth server, then you need to read RFC 7519 (JWT), JWT Best Current Practice, JWT Profile for Access Tokens, and probably some others that I forgot. That\u2019s a lot of material.\n\nWhy not OAuth 3?\n\nSo why am I suggesting an OAuth 2.1? Surely we should instead scrap this existing work and create something simpler and more streamlined?\n\nAs it so happens, that effort is already under way as well, being led by Justin Richer under the name Transactional Authorization, or TXAuth, and likely to end up as OAuth 3. That effort takes a completely greenfield approach, rethinking how OAuth and all its related specs and extensions such as UMA might look if everything were not tied to being an extension of the original OAuth 2.0 RFC 6759. I\u2019m definitely in support of this effort, there are a lot of nice patterns that emerge when you look at it this way, but as we all know, creating a new spec from scratch is not a quick process, much less getting broad adoption within the industry. So while effort on OAuth 3 is under way, which will take literal years to finish, there is room to tidy things up with OAuth 2 in the mean time.\n\nCreating OAuth 2.1\n\nAt the OAuth working group meeting in Singapore last month (IETF 106), I led a discussion about OAuth 2.1 and what it should encompass.\n\nMy main goal with OAuth 2.1 is to capture the current best practices in OAuth 2.0 as well as its well-established extensions under a single name. That also means specifically that this effort will not define any new behavior itself, it is just to capture behavior defined in other specs. It also won\u2019t include anything considered experimental or still in progress.\n\nThere was a general agreement from folks in the room that something like this is needed, and following the official meeting, I led a two-hour breakout session where a dozen or so of us dove into more details and started making a plan.\n\nTorsten, the author of the Security BCP made a comment which I thought framed the discussion well. His goal for OAuth 2.1 is that it should make the Security BCP irrelevant because it already includes everything the Security BCP says. In other words, there should be no need to document the most secure way to implement OAuth, since that should be the only option available when you read the spec.\n\nWhat is OAuth 2.1?\n\nWe still need to discuss the specifics about what form this document will take, whether that is going to be an entirely new RFC that replaces RFC 6749, or a BCP that references the other specs, or something else entirely. However, the overarching goals are:\n\nGive people a starting point which lays out a clear path for what they will need to read\nReduce the number of documents people have to read to understand OAuth and implement it securely\nGet rid of the irrelevant content in old RFCs that has been deprecated, so that readers don\u2019t get through an entire section only to discover a later RFC deprecated it\nLabeling libraries or products as OAuth 2.1 is a lot simpler to understand than having to figure out whether it accurately implements OAuth 2.0 and all the desired extensions\nThe specifics of what will be included in OAuth 2.1 are still up for discussion within the group, and will be in the agenda of the upcoming IETF meetings. The starting point for these discussions is roughly the below.\n\nStart with OAuth 2.0 Core, RFC 6749\nInclude OAuth 2.0 Bearer Tokens, RFC 6750\nAdopt the Security BCP, which removes the Password grant and the Implicit flow\nRequire PKCE for all client types, not just public clients (defined in the Security BCP)\nAdopt the native app and browser-based app BCPs\nInclude the Device Grant as a top-level grant option available (RFC 8626)\nInclude Token Revocation (RFC 7009)\nInclude Authorization Server Metadata (RFC 8414)\nIf an authorization server intends to interoperate with arbitrary resource servers, such as OAuth services and open source projects, then there is an additional set of requirements that includes:\n\n\nToken Introspection (RFC 7662)\n\nJWT Access Tokens (current working group draft)\n\nJWT Best Current Practice (current working group draft)\nOf course all of these points are currently up for debate, so if you have feelings about them, you should definitely join the mailing list and discuss them!\n\nCurrently the biggest question for the group is whether or not OAuth 2.1 should make technically breaking changes. It definitely won\u2019t define anything new itself, but if you look at what the Security BCP says, it requires PKCE for all authorization code grants, even for confidential clients. Since most current deployments of OAuth 2.0 only support PKCE for public clients, that means most current deployments will not be compliant with OAuth 2.1 out of the gate. There are arguments on both sides of this, which was a large part of the discussion during the breakout session last month, with no clear consensus.\n\nThese are the kinds of questions that will be discussed in the coming months within the group. If you have thoughts, I would be more than happy to hear them! Feel free to send an email to the list directly, or even write a blog post in response!\n\nI\u2019m excited for this work to kick off, and looking forward to many more discussions going forward!",
"html": "<p>Trying to understand OAuth often feels like being trapped inside a maze of specs, trying to find your way out, before you can finally do what you actually set out to do: build your application.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/46d6e9431e73669c6e2663922dcf83d262b30cffee93bf7971aaac22f358e2c0.png\" alt=\"oauth-maze.png\" /></p>\n\n<p>While this can be incredibly frustrating, it\u2019s no accident that OAuth is actually made up of many different RFCs, building upon each other and adding features in different ways.</p>\n\n<p>In fact, the \u201ccore\u201d OAuth spec, RFC 6749, isn\u2019t even called a specification, it\u2019s technically a \u201cframework\u201d you can use to build specifications from. Part of the reason for this is because it leaves a lot of things optional, and requires that an implementer makes decisions about things like which grant types to support, whether or not refresh tokens are one-time use, and even whether access tokens should be Bearer tokens or use some sort of signed token mechanism.</p>\n\n<p>This has often been quoted as the biggest failure of OAuth, but is also a large part of the reason OAuth has been successfully deployed at the largest companies at scale over the last 10 years.</p>\n\n<p>OAuth has been patched and extended a <em>lot</em> in the last decade of experience deploying systems using it. It\u2019s been extended in ways the original authors could never even see coming. Keep in mind that when OAuth 2.0 was published in 2012, the iPhone 5 was brand new, the latest browser from Microsoft was Internet Explorer 9, single-page apps were called \u201cAJAX apps\u201d, and CORS was not yet an established W3C standard.</p>\n\n<p>Since 2012, the web and mobile landscape has changed dramatically. More people access the internet from mobile devices than desktop devices, single-page apps are an extremely common way of creating web apps, and countless password database breaches have time and again demonstrated that storing passwords is dangerous.</p>\n\n<h2>The Evolving OAuth 2.0 Landscape</h2>\n\n<p>To address this changing landscape, the OAuth community has patched and added to the OAuth spec over the years. The OAuth core spec (RFC 6749) defines four grant types: Authorization Code, Implicit, Password, and Client Credentials. It used to be the case that the Implicit grant was recommended for both JavaScript apps as well as native apps.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/bb5a39047d757bfbfb43160994e9f5f736eaabe94ed946692673b696bfce74d0.png\" width=\"240\" alt=\"a.png\" /></p>\n\n<p>It became apparent that a better solution was needed for mobile apps, so PKCE (RFC 7636) was created to provide a way to use the Authorization Code flow without a client secret.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/f7b57ae9254bed17a72ee5d619b72e07270eb377138a447a4019596a8e5e2087.png\" width=\"300\" alt=\"b.png\" /></p>\n\n<p>Later, \u201cOAuth 2.0 for Native Apps\u201d (RFC 8252) was published, which recommends that native apps use the Authorization Code flow with the PKCE extension.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/c333c83ff806d63c08707de8dbf56558a1001edbacceaa70a2164e2eb4d7e81b.png\" width=\"360\" alt=\"c.png\" /></p>\n\n<p>A new class of device arose along with a need to use OAuth with them: devices that have no browser or lack a keyboard, such as an Apple TV or YouTube streaming video encoder. An entirely new OAuth grant was created to address this, called the Device Grant, published as RFC 8626.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/0e56fe0a25cdae68126155856bdb557b420009333c8ed590115e18328ee7d506.png\" alt=\"d.png\" /></p>\n\n<p>There are even more patches currently in the works. I am writing a draft for <a href=\"https://oauth.net/2/browser-based-apps/\">best practices for single-page apps</a>, and the latest <a href=\"https://oauth.net/2/oauth-best-practice/\">Security Best Current Practice</a> (BCP) is currently in the final call. The single-page apps draft recommends using PKCE with JavaScript apps and says you should no longer use the Implicit flow. The Security BCP effectively deprecates the Implicit flow as well as the Password grant out of OAuth entirely, and further recommends using PKCE even for web server apps.</p>\n\n<p>So what started out as a list of four grant types has had things added and removed, and now looks more like this.</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/4fbdcfc94f83d860dd44247d383e724644de36b3a8fe65de4785cff9e4af8b8a.png\" alt=\"e.png\" /></p>\n\n<p>Which, if you look closely, actually ends up distilling down to this:</p>\n\n<p><img src=\"https://aperture-media.p3k.io/aaronparecki.com/98f3fe6abaf8f35af1664cf7a28f4a9b7c50389cd98d24c087d44015d44ac8a6.png\" width=\"280\" alt=\"oauth-2-dot-1.png\" /></p>\n\n<p>So what we\u2019ve effectively done is taken the core OAuth RFC, added and removed things, and turned it into an entirely different set of recommendations. The problem is that it requires reading far too many RFCs to understand this landscape.</p>\n\n<p>If you want to implement a secure OAuth solution today, it requires reading: RFC 6749 (OAuth 2.0 Core), RFC 6750 (Bearer Tokens), RFC 6819 (Threat Model and Security Considerations), RFC 8252 (OAuth for Native Apps), RFC 8628 (Device Grant), OAuth for Browser-Based Apps, OAuth 2.0 Security Best Current Practice, RFC 7009 (Token Revocation), RFC 8414 (Authorization Server Metadata), and if you\u2019re also implementing an OAuth server, then you need to read RFC 7519 (JWT), JWT Best Current Practice, JWT Profile for Access Tokens, and probably some others that I forgot. That\u2019s a lot of material.</p>\n\n<h2>Why not OAuth 3?</h2>\n\n<p>So why am I suggesting an OAuth 2.1? Surely we should instead scrap this existing work and create something simpler and more streamlined?</p>\n\n<p>As it so happens, that effort is already under way as well, being led by <a href=\"https://twitter.com/justin__richer\">Justin Richer</a> under the name Transactional Authorization, or TXAuth, and likely to end up as <a href=\"https://oauth.net/3/\">OAuth 3</a>. That effort takes a completely greenfield approach, rethinking how OAuth and all its related specs and extensions such as UMA might look if everything were not tied to being an extension of the original OAuth 2.0 RFC 6759. I\u2019m definitely in support of this effort, there are a lot of nice patterns that emerge when you look at it this way, but as we all know, creating a new spec from scratch is not a quick process, much less getting broad adoption within the industry. So while effort on OAuth 3 is under way, which will take literal years to finish, there is room to tidy things up with OAuth 2 in the mean time.</p>\n\n<h2>Creating OAuth 2.1</h2>\n\n<p>At the OAuth working group meeting in Singapore last month (<a href=\"https://oauth.net/events/2019-11-ietf106/\">IETF 106</a>), I led a discussion about OAuth 2.1 and what it should encompass.</p>\n\n<p>My main goal with OAuth 2.1 is to capture the current best practices in OAuth 2.0 as well as its well-established extensions under a single name. That also means specifically that this effort will not define any new behavior itself, it is just to capture behavior defined in other specs. It also won\u2019t include anything considered experimental or still in progress.</p>\n\n<p>There was a general agreement from folks in the room that something like this is needed, and following the official meeting, I led a two-hour breakout session where a dozen or so of us dove into more details and started making a plan.</p>\n\n<p>Torsten, the author of the Security BCP made a comment which I thought framed the discussion well. His goal for OAuth 2.1 is that it should make the Security BCP irrelevant because it already includes everything the Security BCP says. In other words, there should be no need to document the most secure way to implement OAuth, since that should be the only option available when you read the spec.</p>\n\n<h2>What is OAuth 2.1?</h2>\n\n<p>We still need to discuss the specifics about what form this document will take, whether that is going to be an entirely new RFC that replaces RFC 6749, or a BCP that references the other specs, or something else entirely. However, the overarching goals are:</p>\n\n<ul><li>Give people a starting point which lays out a clear path for what they will need to read</li>\n<li>Reduce the number of documents people have to read to understand OAuth and implement it securely</li>\n<li>Get rid of the irrelevant content in old RFCs that has been deprecated, so that readers don\u2019t get through an entire section only to discover a later RFC deprecated it</li>\n<li>Labeling libraries or products as OAuth 2.1 is a lot simpler to understand than having to figure out whether it accurately implements OAuth 2.0 and all the desired extensions</li>\n</ul><p>The specifics of what will be included in OAuth 2.1 are still up for discussion within the group, and will be in the agenda of the upcoming <a href=\"https://oauth.net/events/\">IETF meetings</a>. The starting point for these discussions is roughly the below.</p>\n\n<ul><li>Start with OAuth 2.0 Core, RFC 6749</li>\n<li>Include OAuth 2.0 Bearer Tokens, RFC 6750</li>\n<li>Adopt the Security BCP, which removes the Password grant and the Implicit flow</li>\n<li>Require PKCE for all client types, not just public clients (defined in the Security BCP)</li>\n<li>Adopt the native app and browser-based app BCPs</li>\n<li>Include the Device Grant as a top-level grant option available (RFC 8626)</li>\n<li>Include Token Revocation (RFC 7009)</li>\n<li>Include Authorization Server Metadata (RFC 8414)</li>\n</ul><p>If an authorization server intends to interoperate with arbitrary resource servers, such as OAuth services and open source projects, then there is an additional set of requirements that includes:</p>\n\n<ul><li>\n<a href=\"https://oauth.net/2/token-introspection/\">Token Introspection</a> (RFC 7662)</li>\n<li>\n<a href=\"https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt\">JWT Access Tokens</a> (current working group draft)</li>\n<li>\n<a href=\"https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp\">JWT Best Current Practice</a> (current working group draft)</li>\n</ul><p>Of course all of these points are currently up for debate, so if you have feelings about them, you should definitely <a href=\"https://oauth.net/about/community/\">join the mailing list</a> and discuss them!</p>\n\n<p>Currently the biggest question for the group is whether or not OAuth 2.1 should make technically breaking changes. It definitely won\u2019t define anything new itself, but if you look at what the <a href=\"https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.1.1\">Security BCP</a> says, it requires PKCE for all authorization code grants, even for confidential clients. Since most current deployments of OAuth 2.0 only support PKCE for public clients, that means most current deployments will not be compliant with OAuth 2.1 out of the gate. There are arguments on both sides of this, which was a large part of the discussion during the breakout session last month, with no clear consensus.</p>\n\n<p>These are the kinds of questions that will be discussed in the coming months within the group. If you have thoughts, I would be more than happy to hear them! Feel free to send an <a href=\"https://oauth.net/about/community/\">email to the list</a> directly, or even write a blog post in response!</p>\n\n<p>I\u2019m excited for this work to kick off, and looking forward to many more discussions going forward!</p>"
},
"author": {
"type": "card",
"name": "Aaron Parecki",
"url": "https://aaronparecki.com/",
"photo": "https://aperture-media.p3k.io/aaronparecki.com/41061f9de825966faa22e9c42830e1d4a614a321213b4575b9488aa93f89817a.jpg"
},
"post-type": "article",
"_id": "6942441",
"_source": "16"
}
What do you use to store your files in a remote location (the “cloud”) that’s not your computer?
{
"type": "entry",
"published": "2019-12-13T01:57:53+00:00",
"url": "https://twitter.com/jackyalcine/status/1205305812714971136",
"content": {
"text": "What do you use to store your files in a remote location (the \u201ccloud\u201d) that\u2019s not your computer?"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"_id": "6942164",
"_source": "2773"
}
New post: Plaidophile: More Corel shenanigans beesbuzz.biz/blog/4477-More…
{
"type": "entry",
"published": "2019-12-13T01:57:05+00:00",
"url": "https://twitter.com/fluffy/status/1205305610021064704",
"content": {
"text": "New post: Plaidophile: More Corel shenanigans beesbuzz.biz/blog/4477-More\u2026",
"html": "New post: Plaidophile: More Corel shenanigans <a href=\"https://beesbuzz.biz/blog/4477-More-Corel-shenanigans\">beesbuzz.biz/blog/4477-More\u2026</a>"
},
"author": {
"type": "card",
"name": "fluffy \ud83d\udc9c",
"url": "https://twitter.com/fluffy",
"photo": "https://pbs.twimg.com/profile_images/1113258016151707648/vzpeXCFt.png"
},
"post-type": "note",
"_id": "6942007",
"_source": "2773"
}
{
"type": "entry",
"published": "2019-12-12T17:42:27-08:00",
"url": "https://beesbuzz.biz/blog/4477-More-Corel-shenanigans",
"syndication": [
"https://indieweb.xyz/en/software",
"https://indieweb.xyz/en/corel",
"https://indieweb.xyz/en/rant"
],
"name": "More Corel shenanigans",
"author": {
"type": "card",
"name": "fluffy",
"url": "https://beesbuzz.biz/",
"photo": "https://beesbuzz.biz/static/headshot.jpg"
},
"post-type": "article",
"_id": "6941837",
"_source": "2778"
}
People don’t want to lose their network (or rather can’t because of work).
This is something that people look over when it comes to suggesting alternatives.
What can we do to help people maintain some level of stability if they looked into other… v2.jacky.wtf//post/0f36b2ba…
{
"type": "entry",
"published": "2019-12-13T00:55:14+00:00",
"url": "https://twitter.com/jackyalcine/status/1205290045508407296",
"content": {
"text": "People don\u2019t want to lose their network (or rather can\u2019t because of work).\nThis is something that people look over when it comes to suggesting alternatives.\nWhat can we do to help people maintain some level of stability if they looked into other\u2026 v2.jacky.wtf//post/0f36b2ba\u2026",
"html": "People don\u2019t want to lose their network (or rather can\u2019t because of work).\nThis is something that people look over when it comes to suggesting alternatives.\nWhat can we do to help people maintain some level of stability if they looked into other\u2026 <a href=\"https://v2.jacky.wtf//post/0f36b2ba-3ce3-4cc6-97a9-02c978b4dda2\">v2.jacky.wtf//post/0f36b2ba\u2026</a>"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"_id": "6940570",
"_source": "2773"
}
“The new phonebook’s here, the new phonebook’s here!” Lovely work, @jezburrows.
{
"type": "entry",
"published": "2019-12-12 16:09-0800",
"url": "https://gregorlove.com/2019/12/the-new-phonebooks-here/",
"photo": [
"https://gregorlove.com/site/assets/files/5718/img_20191212_160749.jpg"
],
"syndication": [
"https://twitter.com/gRegorLove/status/1205280208124874752"
],
"content": {
"text": "\u201cThe new phonebook\u2019s here, the new phonebook\u2019s here!\u201d Lovely work, @jezburrows.",
"html": "<p></p>\n\n<p>\u201cThe new phonebook\u2019s here, the new phonebook\u2019s here!\u201d Lovely work, @jezburrows.</p>"
},
"author": {
"type": "card",
"name": "gRegor Morrill",
"url": "https://gregorlove.com/",
"photo": "https://gregorlove.com/site/assets/files/3473/profile-2016-med.jpg"
},
"post-type": "photo",
"_id": "6940383",
"_source": "95"
}
Cibo Matto were doing the nerdcore thing all the way back in 1995, but were dismissed as a "gimmick." It's a shame that they haven't been recognized as early genre pioneers. en.wikipedia.org/wiki/Cibo_Matt…
{
"type": "entry",
"published": "2019-12-13T00:16:26+00:00",
"url": "https://twitter.com/fluffy/status/1205280280082145281",
"content": {
"text": "Cibo Matto were doing the nerdcore thing all the way back in 1995, but were dismissed as a \"gimmick.\" It's a shame that they haven't been recognized as early genre pioneers. en.wikipedia.org/wiki/Cibo_Matt\u2026",
"html": "Cibo Matto were doing the nerdcore thing all the way back in 1995, but were dismissed as a \"gimmick.\" It's a shame that they haven't been recognized as early genre pioneers. <a href=\"https://en.wikipedia.org/wiki/Cibo_Matto_(EP)\">en.wikipedia.org/wiki/Cibo_Matt\u2026</a>"
},
"author": {
"type": "card",
"name": "fluffy \ud83d\udc9c",
"url": "https://twitter.com/fluffy",
"photo": "https://pbs.twimg.com/profile_images/1113258016151707648/vzpeXCFt.png"
},
"post-type": "note",
"_id": "6939565",
"_source": "2773"
}
“The new phonebook’s here, the new phonebook’s here!” Lovely work, @jezburrows.
{
"type": "entry",
"published": "2019-12-13T00:16:09+00:00",
"url": "https://twitter.com/gRegorLove/status/1205280208124874752",
"photo": [
"https://pbs.twimg.com/media/ELoD9e-WkAAqayp.jpg"
],
"content": {
"text": "\u201cThe new phonebook\u2019s here, the new phonebook\u2019s here!\u201d Lovely work, @jezburrows.",
"html": "\u201cThe new phonebook\u2019s here, the new phonebook\u2019s here!\u201d Lovely work, <a href=\"https://twitter.com/jezburrows\">@jezburrows</a>."
},
"author": {
"type": "card",
"name": "gRegor Morrill",
"url": "https://twitter.com/gRegorLove",
"photo": "https://pbs.twimg.com/profile_images/714490697764716545/je7VCyLC.jpg"
},
"post-type": "photo",
"_id": "6939566",
"_source": "2773"
}
{
"type": "entry",
"published": "2019-12-12T23:48:54+0000",
"url": "https://quickthoughts.jgregorymcverry.com/2019/12/12/checked-into-nathan-hale-ray-middle-school-winter-choral-concert",
"author": {
"type": "card",
"name": "Greg McVerry",
"url": "https://quickthoughts.jgregorymcverry.com/profile/jgmac1106",
"photo": "https://quickthoughts.jgregorymcverry.com/file/2d6c9cfed7ac8e849f492b5bc7e6a630/thumb.jpg"
},
"post-type": "note",
"_id": "6939117",
"_source": "1300"
}
Just a typical day at the @adobe office. Cass and I got our legs squeezed with the @NTRecovery while coworking.
{
"type": "entry",
"published": "2019-12-12T23:43:15+00:00",
"url": "https://twitter.com/andigalpern/status/1205271931106119680",
"photo": [
"https://pbs.twimg.com/media/ELn8Z_7U4AAkVAZ.jpg"
],
"content": {
"text": "Just a typical day at the @adobe office. Cass and I got our legs squeezed with the @NTRecovery while coworking.",
"html": "Just a typical day at the <a href=\"https://twitter.com/Adobe\">@adobe</a> office. Cass and I got our legs squeezed with the <a href=\"https://twitter.com/NTRecovery\">@NTRecovery</a> while coworking."
},
"author": {
"type": "card",
"name": "Andi Galpern",
"url": "https://twitter.com/andigalpern",
"photo": "https://pbs.twimg.com/profile_images/1162560868543893504/uo_XA_EA.jpg"
},
"post-type": "photo",
"_id": "6938692",
"_source": "2773"
}
I got asked this once but to like to do the yicky yicky and I mentally rebooted while crossing the street lol
Yo a lady just came and sat at my desk and asked “So when are you gonna ask me out on a date Chris?”
Ma’am.
{
"type": "entry",
"published": "2019-12-12T22:47:45+00:00",
"url": "https://twitter.com/jackyalcine/status/1205257960303104000",
"quotation-of": "https://twitter.com/AlbertAbstein/status/1205256032726839297",
"content": {
"text": "I got asked this once but to like to do the yicky yicky and I mentally rebooted while crossing the street lol"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"refs": {
"https://twitter.com/AlbertAbstein/status/1205256032726839297": {
"type": "entry",
"published": "2019-12-12T22:40:05+00:00",
"url": "https://twitter.com/AlbertAbstein/status/1205256032726839297",
"video": [
"https://video.twimg.com/tweet_video/ELnt-L0UUAAeBpy.mp4"
],
"content": {
"text": "Yo a lady just came and sat at my desk and asked \u201cSo when are you gonna ask me out on a date Chris?\u201d\n\nMa\u2019am."
},
"author": {
"type": "card",
"name": "Chris Abstein",
"url": "https://twitter.com/AlbertAbstein",
"photo": "https://pbs.twimg.com/profile_images/1186789279168520193/617ZCp5K.jpg"
},
"post-type": "video"
}
},
"_id": "6937058",
"_source": "2773"
}
What kind of bender do you think you’d be? Like from the **#AvatarTheLastAirbender** series.
{
"type": "entry",
"published": "2019-12-12T22:39:41+00:00",
"url": "https://twitter.com/jackyalcine/status/1205255932269207560",
"content": {
"text": "What kind of bender do you think you\u2019d be? Like from the **#AvatarTheLastAirbender** series.",
"html": "What kind of bender do you think you\u2019d be? Like from the **<a href=\"https://twitter.com/search?q=%23AvatarTheLastAirbender\">#AvatarTheLastAirbender</a>** series."
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"_id": "6936909",
"_source": "2773"
}
Yo, fuck patent trolls, FOR REAL.
Also copyright is a fucking weapon of abuse. zdnet.com/article/russia…
{
"type": "entry",
"published": "2019-12-12T22:23:13+00:00",
"url": "https://twitter.com/jackyalcine/status/1205251790138163200",
"content": {
"text": "Yo, fuck patent trolls, FOR REAL.\nAlso copyright is a fucking weapon of abuse. zdnet.com/article/russia\u2026",
"html": "Yo, fuck patent trolls, FOR REAL.\nAlso copyright is a fucking weapon of abuse. <a href=\"https://www.zdnet.com/article/russian-police-raid-nginx-moscow-office/\">zdnet.com/article/russia\u2026</a>"
},
"author": {
"type": "card",
"name": "https://v2.jacky.wtf/follow",
"url": "https://twitter.com/jackyalcine",
"photo": "https://pbs.twimg.com/profile_images/1204190090924183554/4FI9R3lp.jpg"
},
"post-type": "note",
"_id": "6936276",
"_source": "2773"
}
