gertd

Learn Rust or something else if you do not like or cannot stand golang!

This generates high-calorie syntactic sugar just to satisfy an itch.

Run the generated code through the golang-ci linter, which will barf on what is getting created, for example:

``` // Eliminates any 'unused variable' errors _, _, _, _ = err, fileContent, fileContentStrVersion, trimmedLines ```

golang is a procedural language. If you cannot deal with it, don't use it, but please stop polluting the ecosystem.

Exciting to see the AI RAG world connecting with the ReBAC authorization world!

You can, simply use the topazd.exe binary from the topaz_windows_x86_64.zip from the GH releases page (https://github.com/aserto-dev/topaz/releases). Note this is currently not a Windows Service, so not net start topaz. Let me know if that would be interesting.

In simple terms topaz brings a rebac data solution together with OPA, so you only have to create attribute based authorization rules when really needed, to compliment the relation authorization provided by the topaz directory.

I love the fact it is bring relational and attribute based together, happy birthday Topaz !

That is one of the charters of the working group, https://openid.net/wg/authzen/

The key objective is to build upon the existing cornerstones.

Note that this is not necessarily an effort to define yet another authorization architecture or runtime policy language. Instead, the WG will develop OpenID Foundation Final Specifications which leverage existing architectures and protocols as much as possible. Where appropriate, the WG intends to collaborate with international standards development organizations, such as ISO/IEC JTC 1, ITU-T, and IETF, for recognition of these OpenID Foundation specifications.

Which is exactly why using a middleware is an option and therefore a decision the implementor makes.

Many people appreciate the middleware approach as it provides coverage for the API surface with minimal investment, so a great way to get started.

But there is no free lunch

Not having to tied them together into a single process space is an interesting option/ability which would get lost with using it as a library.

Having the authorizer integrate based on contract feels like an option which allows for more freedom of choice and variety of implementations.

I do not believe in one size fits all, nor that there is one to rule them all.

When it comes to integration of external capabilities in OPA there are only two options: make a REST call, or add a built-in.

We provide a set of OPA built-ins which enable the integration which are documented here: https://www.topaz.sh/docs/directory/built-ins.

Endpoint wise you can have N.

Technically names do not have to match, but it certainly makes it easier if you have a pattern to rely on when injecting authorization into a middleware layer.

Very neat! Can it support gRPC, that would be lovely?

Interested to understand how does this compares and relates to https://github.com/99designs/gqlgen. Especially in the area of type system, is this reflection based, materialized types?

@jzelinskie care to respond, I am really interested in the answer?

So the idea is that you create a candidate set of resource keys from the permission system and join that with the external database and / or use it as a post filter?

You can create rules which take in to account that there is a temporary grant, you do need to account for that somewhere in the form of accessible state. This could be achieved using the tenant level resource state, which is immediately updated and can be referenced from the rego rule.

I imaging could provide guarantees about the authenticity of the articles author and guard against plagiarism.

Is there GitLab CI support, similar to the GitHub actions?

I can see how when say medium which is dealing with curated data from my sources could benefit from leveraging a BlockChain or like solution,

To coin that Web 3.0 goes too far in my opinion, as I believe there are many scenarios where one would not want or need this dependency.

I find topic balancing and scaling up and down volumes related to that a royal challenge resulting in having to balance manually to remove/reduce resource bottlenecks.

The policy CLI builds upon the ideas and direction described in https://github.com/open-policy-agent/opa/issues/1413 (May 2019) and attempts to provide a concrete solution for a standard workflow for Policy As Code creation, publishing, sharing, and consumption.

First step was to make the explicit workflow build, tag, push, pull available for OPA while being compatible with the existing formats used by OPA. This enveloping approach, provides the workflow, explicit semantic versioning, labelling and optional signing, capabilities

Step two is to make OPA natively understand and support OCI images.

Next step would be special image types, and multi layering. For example I would love it if we have separate layers for rego, wasm, and data.json, as the data often needs to eleve independent of the rego and wasm code.

This will get added!

There is currently a lot of special casing required, as the OCI spec laying out the Registry API and interactions are not very rich. This limits usability and performance.

But we certainly are going to add support for ohters, ghcr.io, acr etc.