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
Hej.
FYI
Shibboleth SP 3.6 är nu släppt. Ingen säkerhetsrelaterad release utan mer som en förberedelse för Shibboleth SP 4.
De flesta distributioner paketerar 3.5.x så om ni vill köra 3.6 måste ni bygga den själva.
Den stora fördelen med 3.6 är att den flaggar upp konfig som inte längre kommer att fungera i SP 4. Så de som vill förbereda sig inför uppgraderingen kan vilja köra 3.6 en period, övriga kan sitta lugnt i båten :-)
// Björn M.
> Begin forwarded message:
>
> From: Scott Cantor via announce <announce(a)shibboleth.net>
> Subject: Shibboleth Service Provider V3.6.0 now available
> Date: 16 September 2026 at 02:44:01 GMT+2
> To: announce(a)shibboleth.net
> Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
> Reply-To: users(a)shibboleth.net
>
> The Shibboleth Project has released the final minor update to the legacy Service Provider software, V3.6.0.
>
> Source and Windows packages are available [1] and the RPMs are going out to the mirrors now.
>
> There are a couple of notes regarding packages:
>
> - We have published a newer version of libcurl-openssl for Amazon Linux 2, but the OpenSSL version there limits that to a version well behind the latest, best we can do without leveraging non-default packages or doing further custom work.
>
> - We can't maintain build images for CentOS 7 with any reasonable effort at this point, so I have not produced any packages for it. That's in line with our support policy as that has not been a supported platform for a while.
>
> Per the release notes [2], there are no functional changes in this version; it is a "final" release to add deprecation warnings in many places to flag features that are disappearing from the forthcoming V4.0 Agent that replaces this software. Its purpose is to aid deployers in cleaning up Apache (and RequestMapper) configurations to make migration to that version simpler later, and identify deployments using to-be-removed features.
>
> While there may be future patch releases to fix major bugs, fix security issues, or add further warnings, there will be no further feature releases of this software.
>
> Should anybody left be using it, I have produced a final synced up release of the old Moonshot Shibboleth Attribute Resolver library (with deprecation warnings) as well. [3]
>
> Next stop, 4.0.
>
> -- Scott
>
> [1] https://shibboleth.net/downloads/service-provider/3.6.0/
> [2] https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335693/ReleaseNo…
> [3] https://shibboleth.net/downloads/service-provider/extensions/shibresolver/3…
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Tjo!
Mitt minne är ju notoriskt dåligt men jag minns det som att det förut skiljde sig i hur leg-kontrollen skulle göras mellan AL2 och AL3?
Att med AL3 så var man tvungen att kontrollera legitimationen noggrannare genom att ringa register och grejer t.ex.?
Minns jag helt fel?
I v1.2 av https://wiki.sunet.se/spaces/SWAMID/pages/83494432/Identity+Assurance+Level… så under 5.2.5 så nämns "how the Member Organisation minimises the risk of identity fraud;” så det kanske är inkluderat i det?
Jag minns det som att det var tydligare och mer explicit dock?
Tack!
MVH
- Simon
