prabaths

I guess the subtitle of the blog says that - How to Create a Private Ethereum Blockchain from Ground-up?'

Well, in this case it is still a permissionless blockchain. But there are many use cases why we need private permissioned blockchains. For example Hyperledger Fabric is mostly used for different purposes. You can find some use cases here: https://www.ibm.com/blockchain/business-use-cases.html

The EU General Data Protection Regulation (GDPR) is the regulation 2016/679 of the European parliament and of the council, which replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens (and residents) data privacy and to reshape the way organizations across the region approach data privacy. Commonly known as GDPR, was passed as a regulation on 27th April 2016 — and will be effective from 25th May 2018. GDPR became quite prominent due to the heavy penalties introduced by it for violators — which could be as much as 4% of the annual global turnover or €20 Million (whichever is greater)

I assume SPIFFE is more useful to system to system authentication without the end user context - like how Netflix uses short-lived certificates to secure interactions between microservices (https://medium.facilelogin.com/short-lived-certificates-netf...) ?

This was discussed at a Netflix meetup. The official site is www.padme.io. Also you can find the video recording of that meetup from https://www.youtube.com/watch?v=dim85J5cLq4 - OPA and PADME are discussed from 33:49. Also check http://www.openpolicyagent.org/.

Okay - rereading your comments - looks like you have misinterpreted this one.

"A signed JWT is known as a JWS (JSON Web Signature) and an encrypted JWT is known as a JWE (JSON Web Encryption)"

This is a correct statement. This does not mean JWS is a JWT all the time.

This is well highlighted in the blog link I shared with you: https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-du...

"Yes, you read it correctly, the payload of a JWS necessarily need not to be JSON - if you’d like it can be XML too."

Well I am not quite clear from your comment how you interpret. This is my point - as also rightly in the JWT RFC.

"JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted."

"JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization."

A JWT will only exist as a JWS or JWE. It does not exist by itself - its an abstract concept.

Regarding HMAC - its not recommended for the context of this article. It's not a recommended approach to do authentication with shared keys is in a distributed environment.

I agree XACML has lot of complexities. But if you look at the recent developments, you can now have both XACML request and response JSON based - and the communication between the PEP and PDP in a RESTful manner. Also - there is a standard coming up to have a JSON representation of XACML policies. BTW, this blog only presents an architectural model - it can be any policy language. Recently I found Netflix uses the same model for policy distribution but instead of XACML, uses PADME. For me more than the language, the issue XACML having is maintainability, auditability and governance. There are tools around to support that. Even PADME does not solve these problems.

In fact JWT is an abstract concept - I have written a blog about that in detail. Please find it here - https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-du...

HMAC is not recommended - as it will be symmetric key. In fact you will find more details in the above link...

Yes - revocation is always tricky - that's why Netflix moved to short-lived certs - and forgot about cert revocation. Here is a blog I wrote on Netflix model: https://medium.facilelogin.com/short-lived-certificates-netf...

It should be signed by the STS - which is trusted by all the downstream microservices. The STS, who validates the access_token, in the response can send back this signed JWT to the gateway. The STS of the access_token and this JWT can be the same or two different ones, based on the use case...

Well... yes - one way to do that is to have a way to propagate revocation events from the issuer to the up stream applications - and each upstream application, possibly at the gateway level or at an inceptor will check the incoming tokens against a revoked list of tokens. You may also check: http://openid.net/wg/risc/.

Yes... its Identity and Access Management