Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GAP-27] Generic Attestations on REST APIs #69

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

stranger80
Copy link
Contributor

Some Golem/Yagna REST API calls will require a proof of an "attestation" to be passed as credential to the API call, eg. a proof of a multi-sig on a resource Access Control List.

This GAP proposes a generic standard to be used for any attestation-like credentials on Yagna REST APIs.

@approxit
Copy link
Contributor

In first session, we've talked about how ACLs should be attached to requests.

Based on scenario, when some example attestation will be based on digital signing of the payload, we identified the problem, where agent is not the final sender of the request - yagna as a middleman, can modify that payload - hence digital signature can be invalid.

We have talked through possible solutions:

  1. Tell the attestation that it should sign only the subset of payload - which will be per request - by finite set of jsonpointers. Because of large complexity and bringing technical details up positions around "devops", this concept was dropped.
  2. Same as the previous one, but jsonpointers details would be moved from ACL to attestation implementation - which still requires similar maintencance.
  3. Attestation should digitally sign whole payload, where yagna should handle its modifications not by altering payload, but by attaching it next to the payload

Another bit is the case of gas price, which have multiple factors:

  • it is not currently exposed to the agent
  • it could be significant for agent swarms
  • it is not related to receiver yagna, but only to sender yagna
    and by exposing gas price in to the payload it would be:
  • unnecessary sent to receiver yagna
  • be a part of digital signature

Is this looks like gas price be delivered by the agent outside of request payload?

@approxit
Copy link
Contributor

Step 1 - Agent:

yagna_api.accept_invoice(id='abc')

Step 2 - Agent http transport:

POST http://yagna_requestor/invoices/abc/accept
HEADER-ACL: ...

Step 3 - Requestor Yagna web server:

AcceptInvoceCommand(
    agent_data: {
        id: str
    }
    metadata: {
        acl: ...
        extras: ...
    }
)

def handle_http_invoice_accept(ctx, request, id):
    agent_data = request.json()
    agent_data['id'] = id

    metadata = {
        'acl': request.headers('ACL'),
        'extras': ctx.get_extras(),
    }

    ctx.gsb.send(AcceptInvoceCommand(
        agent_data,
        metadata
    ))

Step 4 - Provider Yagna GSB:

AcceptInvoceCommand(
    agent_data: {
        id: str
    }
    metadata: {
        acl: ...
        extras: ...
    }
)

def handle_gsb_invoice_accept(ctx, gsb_packet):
    if not ctx.validate_acl(gsb_packet.metedata.acl, gsb_packet.agent_data):
        raise NoPermissionsError()

    ctx.invoices.accept(gsb_packet.agent_data.id)

    ctx.do_something_with_extras(gsb_packet.metedata.extras)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GAP: Standards GAP Type: Standards
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants