… We’re doing pretty well.

… Also need to get back to standards implementaitons.

… I’m presenting again at the Web Payments F2F in Sapporo Japan.

… a number of members have stepped up and said they want this on the agenda.

… This was called the “Open Payments Foundation”, because we thought this would interesect.

… But, in June, the payments group put credentials on the back-burner.

… The foundation would have hired engineers to do open source implementaions of various standards, but the effort fell off.

… We had submitted with the Software Payment Concervancy, but they haven’t gotten back to us.

… We’re not making good enough progress on creating this organization, and it’s important that we do.

… They want to go standards track with their platform. They’re aligned with our goals, but have different ideas on the distributed hash.

… They’re counter argument as that they want to launch in 5 months, and the Blockchain is out there and can be used.

… We should already have an implementation of WebDHT, but we dont. So, organizations are willing to go forward with Blockchain.

… Problem for us doing this is that noone has put up funding for this yet. It’s a large project which requires the full support of the community to do such implementaitons.

… THey want to collaborate with us, and we should get into a discussion with them about particulars of Blockchain and decentralized ledgers. But, we’re not in a possition as a community to move on this thing. As a result, such a large organization may try to make a de-facto standard, which would be pretty horrible for interoperability.

… For example, Internet of Things devices are too underpowered for the Blockchain. THe easiest counter is to say we have an implementation. But, we’re falling behind.

… This also makes implementaions more complex. We’re trying to keep the complexity down.

… Or, they could be implemented in non-interoperable ways.

… We allow design flexibility so we can fix things down the road, but there should be “one true way” to implement things which will make it easy for organizations to deploy at a low cost.

… We had a dinner where we got together some key decision makers, and it bounced all over the place.

… There’s a realization that the standard creates the plumbing that allows an ecosystem of different systems.

… They’re looking at all kinds of different choices, including Oauth2, JWT, etc.

… There’s a longer-term work that addresses things a trusted pipe doesn’t help.

… It’s important for this group to realize that this is a longer-term project, and not a short-term project.

… I think the IMS is not likelyl to move quickley enough for our needs.

… Presentation focused on work we’re doing here. IMS has also endorced the Open Badge Alliance.

… As we start to see our work converge with IMS, there’s a great opportunity. As John pointed out, there’s an even greater opportunity for machine-to-machine authorization.

… They keep coming back to identity being a big problem. They compare this with Shibolith.

… OAuth/OpenID is overkill for what they want to do.

… For example, centraized vocabularies. It’s open enough to let the market decide.

… The converstaion with dlongley was about revocation of certificates. We talk about the provider hosting in some contexts, and in others the issuer.

… We narrowed this down to the provider hosting the certificates, but the issuer maintaining a reference to see if it’s revoked.

… I’m working on a draft to discuss this ^^^

… The next step is to start writing a lot more about it.

… The criticisms from OpenID Connect and Infocard are that they’re not sure this is the right way to go. We can tell you about our experience.

… We talk about an extensible data model. They think this is overrated; Infocard was very extensible, but noone extended it. This lead to implementation complexities.

… In OpenID Connect we found a way to do this in a clean way, and we think that was the right way to do it. We’re not claiming that we succeeded.

… If you give them 3 options, you can guaranteed 3 non-interoperable implementations. Otherwise, it’s a failure to standardize.

… For choice of storage, they ended up with a bunch of federations that spoke to each other, but didn’t find at generice ID.

… It’s not designed to be as generic and interoperable as what we’re doing. There’s a question of bias, because of self-selecting the audience.

… I believe we heard in this group that we want generic providers and consumers, but this is at odds with the OpenID Connect experience. There are definite providers and consumers.

… They like the privacy-enhanced bits. Portability isn’t important for them; once people select, they don’t move.

… They were very complimentary, and wanted to participate in the work.