Implement signature verification api

[DeD1rk]

Based on a discussion from a long time ago (https://yiviapp.slack.com/archives/C0KCTQ0BC/p1713794023128249) I decided to implement an API endpoint for verifying signatures in the irma server.

Currently, there's no authorization: as the user already has a signature, and authenticator does not prevent doing disclosures with excessive personal data.

However, maybe it should still be implement to prevent freeloading on a public irma server. I'm not sure about that, nor about how that would look. Alternatively, it could also be made configurable whether the endpoint should be available at all. That way, it can be disabled by default, and hosting parties who are afraid of people using it without authentication can still turn it on when reachable only from a private network.

I haven't made docs or implemented implemented any tests (yet). The verification logic is already tested though, and I'm using this without any issues so far in my project.

Let me know if you have any ideas or requests! If you guys are interested in merging this, I can probably take a look at unittests and docs some time.

[saravahdatipour]

The attribute-based signature verification endpoint seems like a nice idea.
The problem with having the endpoint without authentication is that, any public irma server then will be able to process personal data through the verification of signatures, and the irma server has no control over whose data it is processing, which becomes a GDPR problem.
It is also possible to use the existing session authentication mechanisms to authenticate attribute-based signature verification sessions as well.
This is mentioned in the docs here
In irmago, session authentication can be done using any of the structs that implements Authenticator interface.
You can see it in use for example, in

irmago/server/requestorserver/server.go

Lines 247 to 277 in 52fd9f2

	func (s *Server) handleCreateSession(w http.ResponseWriter, r *http.Request) {
	defer common.Close(r.Body)
	body, err := io.ReadAll(r.Body)
	if err != nil {
	s.conf.Logger.Error("Could not read session request HTTP POST body")
	_ = server.LogError(err)
	server.WriteError(w, server.ErrorInvalidRequest, err.Error())
	return
	}
	// Authenticate request: check if the requestor is known and allowed to submit requests.
	// We do this by feeding the HTTP POST details to all known authenticators, and see if
	// one of them is applicable and able to authenticate the request.
	var (
	rrequest irma.RequestorRequest
	requestor string
	rerr *irma.RemoteError
	applies bool
	)
	for _, authenticator := range authenticators { // rrequest abbreviates "requestor request"
	applies, rrequest, requestor, rerr = authenticator.AuthenticateSession(r.Header, body)
	if applies || rerr != nil {
	break
	}
	}
	if ok := s.checkAuth(w, r, rerr, applies, body); !ok {
	return
	}
	s.createSession(w, requestor, rrequest)
	}

[DeD1rk]

@saravahdatipour so you'd like me to take a look at implementing some form of authorization?

Would perhaps a simple boolean 'enable signature verification' config option work? There's no way for irmago to know what kind of attributes are in the signature (or what personal information is in the message) before receiving (and hence processing) it, so fine-grained permissions are not possible here.
For my specific use-case, it is perfectly acceptable to process arbitrary personal data from GDPR perspective, so enabling it (despite using a publicly reachable irma server) would be just fine for me, and I imagine that other uses of it (such as a current thesis project for PubHubs) would also need public access to it, or can just use it on a server that is not publicly reachable. It could be disabled by default of course.

I can see some added value in having a complete requestor authentication system, but as it doesn't quite fit in the existing requestor authentication for session requests, I think that would be a pretty big addition, that's a little beyond my skillset and the time I have.

[saravahdatipour]

The issue here would be that even if we enable it with a flag or similar logic, merging this would mean all future IRMA servers will have this endpoint that if misconfigured can suddenly subject the service provider to GDPR issues.
I understand that for controlled use cases such as yours seems this is no issue, because the requestor party is inherently trusted. But even then, it just can happen that a signature is sent to your server that contains personal data of someone for which you have no GDPR rights to process their personal data.
One way to avoid it could be not having this endpoint public at all and give clear warnings to the developer if this endpoint is publicly accessible, as a caution to misconfiguration.