You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To facilitate use, it would be nice if we could avoid the need for a special header to pass the public key to encrypt downloads for.
This would mean some form of pre-registration. There has been various discussions (e.g. putting in a database), but no implementation that I know of.
One alternate way could be to have a service (e.g. login) allowing to issue a visa (e.g. considering the key a linked identity), possibly a good idea to reach out to LS Login .
LS Login also supports management of ssh keys, including ed25519 keys. Technically it's a different encoding than the native crypt4gh public key format but it encodes the same thing and can be used as a bearer (common crypt4gh tooling also supports reading ed25519 ssh keys directly).
The text was updated successfully, but these errors were encountered:
To facilitate use, it would be nice if we could avoid the need for a special header to pass the public key to encrypt downloads for.
This would mean some form of pre-registration. There has been various discussions (e.g. putting in a database), but no implementation that I know of.
One alternate way could be to have a service (e.g. login) allowing to issue a visa (e.g. considering the key a linked identity), possibly a good idea to reach out to LS Login .
LS Login also supports management of ssh keys, including ed25519 keys. Technically it's a different encoding than the native crypt4gh public key format but it encodes the same thing and can be used as a bearer (common crypt4gh tooling also supports reading ed25519 ssh keys directly).
The text was updated successfully, but these errors were encountered: