I dagsläget finns en begränsning att upp till och med 12 personer kan signera ett och samma dokument i eduSign. Detta beror på att det är antalet signaturer som får plats på den grafiska representationen av signatursidan. Vi upplever inte detta vara ett problem, men skulle det vara så att många organisationer vill att vi ökar denna begränsning kommer vi se över frågan.

Varför använder eduSign tidzonen UTC?

Beroende på vart i världen du befinner dig så kan tiden på signerade dokument i eduSign se ut att vara en annan en den lokala tiden. Detta beror på att eduSign använder tidszonen UTC när tjänsten signerar dokument.
Det handlar till viss del om att minska tvetydigheten. Dels rent teknisks då UTC är vanligare att använda än t.ex. CET, speciellt internationellt då många utgår från just UTC när tider skall konverteras. En annan fördel är att UTC alltid är UTC, om man väljer CET som exempel så skiftar det mellan CET till CEST på sommaren.

Jag har en ide om en ny feature!

...

I dagsläget har vi satt en gräns på 20MB på storleken på dokument som går att ladda upp i eduSign och signera.

Vi har i dagsläget ingen dedikerad statistiktjänst för just signeringar. Däremot går det att få en indikation på användandet genom att se på Géants f-ticks tjänst.
- Gå till https://f-ticks.edugain.org/index.html
- Klicka på Statistics -> SPs
- Välj last 12 month uppe till höger
- Välj er IdP som idp (om det inte kommer upp något resultat betyder det förmodligen att er IT-avdelning inte slagit på fLog mot Sunet/Swamid)
- Välj signservice.edusign.sunet.se som sp
I ovan förfarande ser man hur många autentiseringar som gjorts från en IdP mot signservice. Dvs hur många gång en användare har signerat i eduSign. Att notera är dock att "en signering” kan även vara en bulksignering i eduSign, så själva antalet dokument som signeras kan vara högre än antalet autentiseringar mot signservice.
OBS Kör en IdP ADFS går det inte att rapportera f-ticks just nu, men en uppdatering av ADFS toolkit som väntas till våren (2024) kommer kunna ändra på just detta.

...

Som standard går det bara att bjuda in personer att signera via den e-post de har kopplat till sitt "mail" attribut i deras IdP.
Men om en organisation konfigurerar att släppa även mailLocalAddress från deras IdP till eduSign så går det också att bjuda in personer att signera via deras e-postalias. Förutsatt att mailLocalAdress populeras med de lokala e-postalias som används inom organisationen.
Attributet som behöver släppas till eduSign är alltså mailLocalAddress enligt http://www.geant.net/uri/dataprotection-code-of-conduct/v1 entitets kategori (aka CoCov1) eller https://refeds.org/category/code-of-conduct/v2 entitets kategori (aka CoCo v2).
Se även mer information på SWAMIDs wiki.

...