Hej.
Vi vill stämma av en sak gällande hur vår IdP hanterar authnContextClassRef, då vi ibland kommer skicka värdet urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified till tjänster i federationen.
Vår inloggning kommer bygga på Microsoft Entra ID där användare ofta loggar in helt lösenordslöst. För oss känns det mest korrekt att skicka detta värde som det är, istället för att maskera inloggningen och skriva om den till urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, vilket inte är sant.
Entra ID skickar även urn:oasis:names:tc:SAML:2.0:ac:classes:Password. Vårt mål är att skriva om det till PasswordProtectedTransport, men det har vi inte lyckats med ännu. Så det kan också vara ett värde vi kommer skicka.
Vi utgår från att detta kommer fungera i federationerna, men säg till om ni ser några tekniska problem med det eller om ni har några invändningar.
Med vänlig hälsning,
Eric Johansson
Karolinska Institutet
När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/om-ki/integritetsskyddspolicy>.
Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here<https://staff.ki.se/data-protection-policy>.
FYI
// Björn M.
Begin forwarded message:
From: Philip Smart via announce <announce(a)shibboleth.net>
Subject: WebAuthn plugin V1.4.3 now available
Date: 12 October 2026 at 21:07:52 GMT+2
To: "announce(a)shibboleth.net" <announce(a)shibboleth.net>
Cc: Philip Smart <Philip.Smart(a)jisc.ac.uk>
Reply-To: users(a)shibboleth.net
The Shibboleth Project has released version 1.4.3 of the WebAuthn Authentication Plugin.
This patch release primarily updates the Yubico WebAuthn libraries to version 2.10.1, which fixes a bug in FIDO Metadata processing and improves trust root handling.
For full details, please refer to the release notes [1].
— Phil Smart, on behalf of the team
[1] https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3394928781/We…
Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
--
To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Hej.
I samband med en översyn av våra processer kring samordningsnummer så noterar vi en sak som väcker frågor. Vår implementation gällande generering av schacDateOfBirth baseras på informationen på SWAMID:s Wiki https://wiki.sunet.se/spaces/SWAMID/pages/69042390/Svenska+personnummer+nor… samt https://wiki.sunet.se/spaces/SWAMID/pages/69042384/Example+of+a+standard+at…. Där förespråkas (i princip) att direkt bara plocka de första 8 tecknen från norEduPersonNIN, vilket innehåller personnummer eller samordningsnummer, dock ej interimspersonnummer. Vad som blir fel här är i så fall att schacDateOfBirth innehåller ett värde som inte är ett datum i de fall vi använder norEduPersonNIN som källa. Taget från specen på https://wiki.refeds.org/display/STAN/SCHAC+Releases?preview=/44957731/12890… så skall värdet vara av formatet "Numeric value YYYYMMDD, using 4 digits for year, 2 digits for month and 2digits for day as described in RFC 3339 'Date and Time on the Internet:Timestamps' as reference using the 'full-date' format from paragraph 5.6 but without the dashes.".
Nu vill jag justera vår implementation så att vi justerar bort de extra 60 dagarna från samordningsnummer, detta så att vi följer standarden så att vi för en person släpper samma schacDateOfBirth som t.ex. en annan tjänst gör. Rätt eller fel?
Är det någon som ser problem/risker med att byta implementationen? Vi kommer ju i så fall släppa ändrade schacDateOfBirth för personer. Är det någon annan som tidigare noterat detta och som vill dela med sig av erfarenheter av en justering? Har vi inom SWAMID ett undantag i hanteringen av detta fält, som gör att vi oss emellan förväntas kunna skicka samordningsvärden istället? Problemet jag upplever blir när vi autentiserar mot tjänster som förväntar sig "korrekta" datum.
Med vänlig hälsning
/Johan
_________________________________________
Johan Hjortskull
Systemarkitekt
Linnéuniversitetet
IT-avdelningen
391 82 Kalmar / 351 95 Växjö
Lnu.se
Vi sätter kunskap i rörelse för en hållbar samhällsutveckling. Linnéuniversitetet - ett modernt, internationellt universitet i Småland.
Vi behandlar personuppgifter enligt reglerna i Dataskyddsförordningen, se Lnu.se/personuppgifter<https://lnu.se/mot-linneuniversitetet/kontakta-och-besoka/personuppgifter/>.
The real-time monitoring of gas consumption across residential, commercial, and industrial applications is being enabled by smart gas meters that provide accurate data, remote reading, and enhanced customer engagement. Analysis presented by Market Research Future reveals that as utilities seek to improve efficiency, smart gas meters continue to gain adoption.
Report Key Statistics
Market Research Future's analysis indicates that the AMI Gas Meter Market was valued at USD 4,129.28 million in 2024, with projections to reach USD 8,420.28 million by 2035 at a compound annual growth rate of 6.69%.
Conclusion
The AMI Gas Meter Market continues to evolve with advancing technology and changing customer requirements. While challenges related to privacy, data security, and acceptance persist, ongoing innovation ensures that meters will continue to improve. The evolution toward behavioral analytics and demand response will define the competitive landscape through 2035.
Read More: https://www.marketresearchfuture.com/reports/ami-gas-meter-market-33675
The real-time monitoring of gas consumption across residential, commercial, and industrial applications is being enabled by smart gas meters that provide accurate data, remote reading, and enhanced customer engagement. Analysis presented by Market Research Future reveals that as utilities seek to improve efficiency, smart gas meters continue to gain adoption.
Report Key Statistics
Market Research Future's analysis indicates that the AMI Gas Meter Market was valued at USD 4,129.28 million in 2024, with projections to reach USD 8,420.28 million by 2035 at a compound annual growth rate of 6.69%.
Smart Meters dominate the technology segment. Residential Consumers represent the fastest-growing end-use segment.
Industry Trends: Customer Engagement and Energy Efficiency
The most significant trend in smart gas meters is enhanced customer engagement.
Energy efficiency insights are driving adoption.
Real-time data enables behavioral changes.
Challenges: Privacy and Data Security
Privacy considerations affect deployment.
Data security requirements are stringent.
Consumer acceptance varies by region.
Future Outlook: Behavioral Analytics and Demand Response
The future of smart gas meters lies in behavioral analytics.
Demand response integration will enable grid support.
Advanced features will improve customer value.
Expert Discussion: Meter Selection
Industry observations from Market Research Future highlight the importance of meter selection.
Communication capabilities affect functionality.
Data management affects value.
Conclusion
The AMI Gas Meter Market continues to evolve with advancing technology and changing customer requirements. While challenges related to privacy, data security, and acceptance persist, ongoing innovation ensures that meters will continue to improve. The evolution toward behavioral analytics and demand response will define the competitive landscape through 2035.
Read More: https://www.marketresearchfuture.com/reports/ami-gas-meter-market-33675
Byte av användaridentifierare i Ladok för studenter
I samband med leverans av 3.4.0 onsdagen den 7 oktober byter Ladok användaridentifierare i Ladok för studenter från ePPN till subject-id.
Vad innebär förändringen?
Alla lärosäten (och eduID) skickar redan idag giltiga subject-id för sina studenter till Ladok. Det innebär att inga anpassningar behöver göras i lärosätenas inloggningstjänster (SWAMID-IdP) inför bytet.
Idag används scope-delen av ePPN i Ladok för studenter för att avgöra vilket lärosäte som ska vara förvalt vid inloggning. Efter bytet kommer Ladok i stället att använda scope-delen av subject-id för samma ändamål. Eftersom Ladok för studenter endast använder scope för att identifiera lärosätet förväntas det heller inte bli någon påverkan på lärosäten eller studenter. Några lärosäten har annat scope i subject-id jämfört med ePPN. För dessa lärosäten finns redan båda dessa scopes i Ladok, så ingen påverkan förväntas på grund av detta.
Det förekommer ibland inloggningar i Ladok för studenter från diverse lärosäten där subject-id saknas eller har ogiltig syntax (exempelvis med en punkt (.) eller ett understreck (_) i användardelen). Det har hittills handlat om felkonfigurering i IdP:n eller asynkron generering av subject-id i IdP:n. Från och med onsdagen kommer studenter i de fallen att få ett felmeddelande och inte kunna logga in. Var förberedd på eventuella supportärenden rörande detta.
Varför byter vi till subject-id?
Bytet till subject-id görs för att göra det möjligt för studenter att koppla ytterligare inloggningsmetoder till Ladok, exempelvis inloggning från ett utländskt lärosäte eller via eduID, utöver alternativ inloggning via eIDAS och Freja för utländska personer.
Ladok för personal
Ladok planerar även för byte till subject-id för personal. Detta har större påverkan då ePPN (och snart i stället subject-id) används för att identifiera användare i Ladok. Vi återkommer med mer information när det närmar sig byte även i Ladok för personal.
/Fredrik
Fredrik Domeij
----------------------------------
Ladok Operations
IT-stöd och systemutveckling (ITS)
Umeå universitet
901 87 Umeå
----------------------------------
Telefon: +46 (0)90 786 65 43
Mobil: +46 (0)70 303 78 36
----------------------------------
fredrik.domeij(a)umu.se<mailto:fredrik.domeij@umu.se>
www.umu.se/it-stod-och-systemutveckling<http://www.umu.se/it-stod-och-systemutveckling>
Hej på er alla som använder ADFS Toolkit,
Hashalgoritm SHA1 är utfasad (deprecated) av säkerhetsskäl. Standardkonfigurationen av ADFS Toolkit är att den ställer in SHA1 som standardalgoritm för SHA* eftersom verktyget inte kan se skillnad på de olika varianterna. Det är nu dags att åtgärda så att SHA256 är standard istället för SHA1. Vi har uppdaterat vår tips- och trixsida ADFS Toolkit Tips & Trix - Sunet Wiki<https://wiki.sunet.se/spaces/SWAMID/pages/254182664/ADFS+Toolkit+Tips+Trix> för hur man gör detta genom konfiguration av ADFS Toolkit. Två lärosäten har redan gjort detta efter att Swamid Operations har fått önskemål från den danska federationen WAYF, de tillåter inte längre SHA1.
Pål
Tjo!
Har det diskuterats i eduGAIN eller REFEDS om best practices kring OpenID Connect ännu?
Det jag syftar mest på är:
* Namngivning av attribut (typ eduPersonEntitlement t.ex.)
* Tillåtna grant types
* Krav på PKCE
* Krav på DPoP
MVH
- Simon
Hej!
Enligt SWAMID SAML WebSSO Technology Profile (3.2, 3.3 och 6.6.2) ska en entitet årligen bekräfta
att den uppfyller teknologi-profilen samt ha tidsmässigt giltigt certifikat.
Följande entitet har trots påtryckning inte bekräftats eller har ett certifikat som gått ut och kommer därför raderas 2026-09-30 ur federationen.
* https://sam.control.lth.se/shibboleth
Vet ni med er att entiteten används vid ert lärosäte behöver ni skyndsamt eskalera detta
till rätt instans inom er organisation.
Det går att följa status på dessa entiteter via vår felsida:
https://metadata.swamid.se/admin/?action=ErrorList
Finns entiteten kvar är den ännu inte hanterad (uppdateras varje onsdag morgon). Last
Confirmed/Validated uppdateras dock löpande.
--
jocar
Swamid Operations