Skip to content

An extended query API that can extract information#21

Open
saoirse-a wants to merge 1 commit into
eclipse-biscuit:mainfrom
saoirse-a:extended-query-api
Open

An extended query API that can extract information#21
saoirse-a wants to merge 1 commit into
eclipse-biscuit:mainfrom
saoirse-a:extended-query-api

Conversation

@saoirse-a
Copy link
Copy Markdown
Contributor

@saoirse-a saoirse-a commented May 20, 2026

Several related changes extend the query API to make it capable of extracting information from the token, similar to Rust's query API.

Both Authorization and Biscuit gain new methods: queryValues and queryValuesExpectingOne. These take a query somewhat similar to the existing boolean query APIs, but also have a result parameter to specify which results should be taken out of the token.

The result parameter is a repeated sequence of tuples containing a variable name as well as a type; the return value of these APIs is an array of tuples or just a tuple containing the values that satisfy that query. For example:

let (userID, serviceName) = token.queryValuesExpectingOne(
    result: ("u", Int.self), ("s", String.self)
) {
    Predicate("user", Term(variable: "u"))
    Predicate("service", Term(variable: "s"))
}

Like rules, checks and policies these respect trusting scopes and will only return results that can be derived from the specified trusting scope (authority by default).

Because multiple values could possibly satisfy the query, queryValues returns an array of tuples; if it would be an error for a token or authorization to satisfy the query multiple times, queryValuesExpectingOne will throw an error in that case and returns a single tuple.

To support querying an authorization, the Authorization type returned by authorizing a biscuit now also stores the fact resolution that occurred during authorization so that it can support querying facts about the authorization (incorporating facts from both the biscuit and the authorizer used to authorize it). Some refactors in Resolution were done because of this as well.

To support downcasting Value and MapKey to specific types (ints, strings, etc), new protocols ExpressibleByValue and ExpressibleByMapKey are added, with conformances for all of the standard value types. These could also be used to support down casting values to domain specific types in applications (for example encoding enums as integers).

Several related changes extend the query API to make it capable of
extracting information from the token, similar to Rust's query API.

Both Authorization and Biscuit gain new methods: queryValues and
queryValuesExpectingOne. These take a query somewhat similar to the
existing boolean query APIs, but also have a result parameter to specify
which results should be taken out of the token.

The result parameter is a repeated sequence of tuples containing a
variable name as well as a type; the return value of these APIs is an
array of tuples or just a tuple containing the values that satisfy that
query. For example:

```swift
let (userID, serviceName) = token.queryValuesExpectingOne(
    result: ("u", Data.self), ("s", String.self)
) {
    Predicate("user", Term(variable: "u"))
    Predicate("service", Term(variable: "s"))
}
```

Like rules, checks and policies these respect trusting scopes and will
only return results that can be derived from the specified trusting
scope (authority by default).

Because multiple values could possibly satisfy the query, queryValues
returns an array of tuples; if it would be an error for a token or
authorization to satisfy the query multiple times,
queryValuesExpectingOne will throw an error in that case and returns a
single tuple.

To support querying an authorization, the Authorization type returned by
authorizing a biscuit now also stores the fact resolution that occurred
during authorization so that it can support querying facts about the
authorization (incorporating facts from both the biscuit and the
authorizer used to authorize it). Some refactors in Resolution were done
because of this as well.

To support downcasting Value and MapKey to specific types (ints,
strings, etc), new protocols ExpressibleByValue and ExpressibleByMapKey
are added, with conformances for all of the standard value types. These
could also be used to support down casting values to domain specific
types in applications (for example encoding enums as integers).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant