Add SetContext on Builder interface and GetContext on Biscuit struct.

[Benoit12345]

To be able to set a context and retrieve it form a biscuit.

[seh]

What is a "context" in this context?

[Benoit12345]

"context" is the second field of the block liked it is indicated into the spec:

message Block {
  repeated string symbols = 1;
  optional string context = 2;
  optional uint32 version = 3;
  repeated FactV2 facts_v2 = 4;
  repeated RuleV2 rules_v2 = 5;
  repeated CheckV2 checks_v2 = 6;
  repeated Scope scope = 7;
  repeated PublicKey publicKeys = 8;
}

And the goal is to be able to be equivalent to the java biscuit library (https://github.com/biscuit-auth/biscuit-java/blob/a863cd8c0bd45ad1e36390ce777741e49417da0e/src/main/java/org/biscuitsec/biscuit/token/builder/Biscuit.java#L119)

if you're question is "are you talking about a Go std context ?", the answer is no but the context from biscuit specification.

[seh]

"context" is the second field of the block liked it is indicated into the spec:

I did see that field in the IDL before asking the question here, but I'm wondering what a typical value would be for such a "context", who sets it, who consumes it, and why.

[divarvel]

"context" is the second field of the block liked it is indicated into the spec:

I did see that field in the IDL before asking the question here, but I'm wondering what a typical value would be for such a "context", who sets it, who consumes it, and why.

It is intended as a way to embed a payload outside datalog. so something freeform that would not be directly used in the authorization context. It’s a remnant of early biscuit days, meant as some kind of escape hatch.

[seh]

It’s a remnant of early biscuit days, meant as some kind of escape hatch.

It sounds like something we'd like to get rid of, but can't now, because the libraries for other languages allow writing to and reading from this Protocol Buffer message field. This patch makes it more likely that we'll preserve this field for a long while.

[Benoit12345]

Hello @seh,
Thank you for your feedback.
That may be so. But if you want to break the backwards compatibility, you need to do it in a major release. This fix can be applied to a minor version and allow compatibility with older/current versions in other languages (which is not the case at the moment).

[tnerolftnerolf]

Hello @seh,
Our issue is that we need to implement in Go something compatible with an existing Java application that currently uses this field , and which we can't change this "legacy" java app..
The biscuits tokens generated by our Go code currently fail to be validated by the existing Java application.
We really would like to avoid to fork your repo if we can avoid it - but we're currently blocked on both sides.

[seh]

We really would like to avoid to fork your repo if we can avoid it - but we're currently blocked on both sides.

Thank you for the explanation, but as much as I'd like to help, I'm not your intended audience, as I'm merely a contributor here for now, and not a maintainer. I don't have any authority to approve proposed changes within this repository.

I expect that you'll need to appeal to @divarvel, who has been handling reviews at least since I started proposing changes here.

[tnerolftnerolf]

Thanks @seh . @divarvel can you please provide your feedback ?

[divarvel]

I think that for consistency, reading the context of not just the authority block would be good as well, but definitely not a blocker, given how little context is used in practice