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
There's also Quorum, the open source enterprise blockchain based on Ethereum. It's got privacy and zksnarks and pluggable consensus and a decompiler and a consortium and everything.
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...) ?
Thats the primary motivation and main focus for SPIFFE. Providing service to service identity. However because its not breaking any of the standards its potentially applicable in other contexts. The SPIFFE SVID (the certificate standard) doesnt do anything wierd or different with TLS certs (which is actually a strength) it more sets out a way to use the current existing cert infrastructure to provide identity.
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.
I've done a fair bit of reading around policy-based authorization but have never heard of PADME. For the life of me I can't find anything about it in any Google searches. Can you point me at a reference for any information about it?
Forgive me if I don't find your own blog a decent citation. Re-reading your first article a bit closer, I can see how you might interpret it, I think (and perhaps I was not charitable enough during my first read), but I still think it is perilously close to mixing JWS being a concrete serialization of a JWT (this is correct) with JWS being a JWT (this is not).
JWS is simply a format that contains a signature for an arbitrary (that is, not always JWT) payload. See the "typ" header in the JWS RFC (in fact, see the entire RFC)[1]; were a JWS always a JWT, we would have no need for "typ". In fact, the RFC for JWS never mentions JWT in the normative parts of the standard — it is only ever mentioned during examples, since JWT is perhaps the primary consumer of the JWS standard. It calls this out, explicitly:
> While the first three examples all represent JSON Web Tokens (JWTs) [JWT], the payload can be any octet sequence
JWT is the concrete thing in that it is a JSON document encoding a set of claims, and comes either signed (wrapped in a JWS) or encrypted (wrapped in a JWE). JWT's RFC[2] states this fairly directly:
> 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
While I see what you're getting at with "JWT is an abstract concept" — that you need to wrap a JWT inside a JWS or a JWE — that does not mean that all JWSs are JWTs, and while the text can certainly be interpreted as "you must wrap a JWT in either a JWS or a JWE", I feel it toes the line too close to "all JWS's are JWTS", particularly at, "A signed JWT is known as a JWS". Having a JWS doesn't imply that it is a JWT; for example, the ACME protocol uses JWS, but not JWT. The distinction here is subtle, but important, I feel.[3]
> HMAC is not recommended - as it will be symmetric key. In fact you will find more details in the above link...
Not recommended by who? For what reasons?
Your article never mentions HMAC AFAICT (it mentions MAC in the process of describing JWS, but no further). And yes, use of HMAC implies a symmetric key, but that isn't necessarily insecure: it just means that anything that wishes to validate JWTs signed with that key must have the key to do so, and thus, must be trusted with that key. If you have a single service (say, an "auth" service) that is responsible for validating JWTs, this works fine, and is a great tradeoff for the additional complexity that signing w/ RSA keys brings. E.g.,
1.
client -- login --> auth_service
<-- JWT --
2.
client -- JWT+cmd --> foo_service
-- is this JWT valid? --> auth_service
<-- yes, it is --
<-- success --
Here, the HMAC key only needs to reside on the auth service, so it is reasonably well contained. The tradeoff, of course, is that we need to make a network request to auth service to validate JWTs, but we don't need to deal with RSA. For some setups, this is perfectly acceptable. (Swapping out RSA keys directly here results in no more or less "secret" stuff on any given node.)
The big advantage to RSA keys, of course, is that any service can verify JWTs without being able to issue them, but if you want to swap out the secret (the private key), you'll need to touch a lot more places, or have some infrastructure to distribute the public key.
[3]: Doubly so since I feel there is a lot of ill-will towards JWT, and many misconceptions about it. It's a good format, IMO, but the messaging around it needs to be crystal clear if people are going to ever stop fearing and start understanding it.
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.
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/.
Like a revocation list of JTIs in an in-memory distributed cache to be checked by the edge service, yes not a bad idea, though there is a cost involved there.
