Hi all, IANA has completed their updates to the registry at <https://www.iana.org/assignments/scim/scim.xhtml#server-related>.
We have now received all necessary approvals and are ready to move this document forward in the publication process at this time. The AUTH48 status page for this document is available here: http://www.rfc-editor.org/auth48/rfc9944. Thank you all for your time and careful attention during the AUTH48 process. All the best, Kaelin Foody RFC Production Center > On May 4, 2026, at 9:05 AM, Deb Cooley <[email protected]> wrote: > > I approve. > > Deb > > On Mon, May 4, 2026 at 8:38 AM Kaelin Foody <[email protected]> > wrote: > Hi *Deb, Eliot, > > *Deb - We have updated the text per Eliot’s most recent reply, but it seems > no further changes are desired here. Please review and let us know if the > current set of updates are acceptable. Please see > https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html. > > Eliot - We have updated the files as requested. Please review and let us know > if any additional updates are needed or if you approve the RFC for > publication. > > We will request that IANA make their relevant changes after we receive all > other approvals listed on the AUTH48 status page. > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9944 > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9944.txt > https://www.rfc-editor.org/authors/rfc9944.pdf > https://www.rfc-editor.org/authors/rfc9944.html > https://www.rfc-editor.org/authors/rfc9944.xml > > Diff files showing changes between the last and current version: > https://www.rfc-editor.org/authors/rfc9944-lastdiff.html > https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by side) > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9944-auth48diff.html > https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9944-diff.html > https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) > > Thank you, > > Kaelin Foody > RFC Production Center > > > On Apr 27, 2026, at 2:57 AM, Eliot Lear <[email protected]> wrote: > > > > Ok. I’m back, tanned, with much more knowledge of the Greek Mycenaean and > > Archaic periods, and raring to go. I’ve reviewed the diffs and I want to > > also address Deb’s points. > > > > First, about “read-only” and “immutable”. This is an artifact of RFC 7643. > > “Read-only” means just that. “Immutable” means it can be written once. > > > > Second, everywhere in the draft, the term should be “read-only” not “read > > only” (this is a regression). Case can remain as is. > > > > Finally: > > > > > > > >> On 23 Apr 2026, at 06:52, Kaelin Foody <[email protected]> wrote: > >> > >> > >>> b) Should the update below be implemented? > >>> > >>> Appendix B.6: > >>> Two additional instances of “...:Devices” (plural) appear in this > >>> section. Should these instances be updated to “:Device” (singular) as > >>> well? > > > > > > Yes, please. > > > > Regards, > > > > Eliot > > > >> > >> We will request that IANA make their relevant changes after we receive all > >> other approvals listed on the AUTH48 status page. > >> > >> All best, > >> > >> Kaelin Foody > >> RFC Production Center > >> > >>> On Apr 17, 2026, at 7:02 AM, Hassan <[email protected]> wrote: > >>> > >>> Hi Kaelin, > >>> > >>> Thank you for the updates. Approved from my end. > >>> > >>> On Tue, Apr 14, 2026 at 4:32 PM Kaelin Foody > >>> <[email protected]> wrote: > >>> Hi Eliot, > >>> > >>> Thanks for your reply and letting us know you will be out of office -- we > >>> will wait on your reply accordingly. > >>> > >>> We have updated the files and Section 6.3.1 as requested. Please review > >>> the two matters below at your convenience: > >>> > >>> a) For the item below, we have removed a space from the left margin for > >>> both the “location” line (seen below) and for the “resourceType” line > >>> that follows it, to preserve original indentation. Please review this > >>> update in Appendix A.1 for correctness. > >>> > >>>>> Appendix A.1: > >>>>> We have updated this line per item #6, but it is now one character too > >>>>> long. Please review and let us know where to insert a line break for > >>>>> the line below: > >>>>> > >>>>> "location": "https://example.com/v2/ResourceTypes/EndpointApps”, > >>>> > >>>> I think you can just indent one space. > >>> > >>> > >>> b) Should the update below be implemented? > >>> > >>>>> Appendix B.6: > >>>>> Two additional instances of “...:Devices” (plural) appear in this > >>>>> section. Should these instances be updated to “:Device” (singular) as > >>>>> well? > >>> > >>> > >>> Please review the items above and let us know if there are any > >>> outstanding updates remaining. > >>> > >>> The AUTH48 status page for this document is available here: > >>> https://www.rfc-editor.org/auth48/rfc9944 > >>> > >>> — FILES (please refresh): — > >>> > >>> The updated files have been posted here: > >>> https://www.rfc-editor.org/authors/rfc9944.txt > >>> https://www.rfc-editor.org/authors/rfc9944.pdf > >>> https://www.rfc-editor.org/authors/rfc9944.html > >>> https://www.rfc-editor.org/authors/rfc9944.xml > >>> > >>> Diff files showing changes between the last and current version: > >>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by side) > >>> > >>> Diff files showing changes made during AUTH48: > >>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side by > >>> side) > >>> > >>> Diff files showing all changes: > >>> https://www.rfc-editor.org/authors/rfc9944-diff.html > >>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) > >>> > >>> All the best, > >>> > >>> Kaelin Foody > >>> RFC Production Center > >>> > >>> On Apr 11, 2026, at 5:51 AM, Eliot Lear <[email protected]> wrote: > >>>> > >>>> Hi Kaelin, > >>>> > >>>> Below are my answers. Please be advised, I’m going on two weeks of > >>>> holiday and will have a limited ability to respond or review changes. > >>>> Also see below for the one remaining other issue which is mildly > >>>> substantial but hopefully not controversial. > >>>> > >>>> > >>>>> On 9 Apr 2026, at 20:23, Kaelin Foody <[email protected]> > >>>>> wrote: > >>>>> > >>>>> Hi Eliot, all, > >>>>> > >>>>> We have updated the files as requested. These updates are best viewed > >>>>> here: https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html. > >>>>> > >>>>> A few follow-up questions regarding these updates: > >>>>> > >>>>> a) Section 6.3.1, Table 2: > >>>>> We have updated this table accordingly. May we also add a value for > >>>>> “Imm” in the legend that appears after this table? > >>>>> > >>>>> Perhaps: > >>>>> Imm = Immutable > >>>> > >>>> Yes. > >>>> > >>>>> > >>>>> b) Section 7.6.2, Table 8: > >>>>> In the “Mutable” column of this table, should the $ref attribute’s > >>>>> value be updated from “R” to “RO” as well (to match the updates made to > >>>>> devContEntEndpoint and telEntEndpoint)? > >>>> > >>>> Yes. > >>>> > >>>>> > >>>>> c) Appendix A.1: > >>>>> We have updated this line per item #6, but it is now one character too > >>>>> long. Please review and let us know where to insert a line break for > >>>>> the line below: > >>>>> > >>>>> "location": "https://example.com/v2/ResourceTypes/EndpointApps”, > >>>> > >>>> I think you can just indent one space. > >>>> > >>>>> > >>>>> d) Appendix B.6: > >>>>> Two additional instances of “...:Devices” (plural) appear in this > >>>>> section. Should these instances be updated to “:Device” (singular) as > >>>>> well? > >>>>> > >>>>> We will request that IANA make their relevant changes and request AD > >>>>> approval after we receive your remaining updates. > >>>> > >>>> > >>>> > >>>> In Section 6.3.1, we wrote: > >>>> > >>>> OLD: > >>>> > >>>>> subjectName:When present, a string that contains one of two names… > >>>> > >>>> If certificateInfo is present then subjectName must be present. > >>>> Otherwise we haven’t given sufficient implementation guidance on how to > >>>> identify a valid identity. Therefore, the proposed change is: > >>>> > >>>> NEW: > >>>> > >>>>> subjectName:A string that contains one of two names > >>>> > >>>> The table already indicates that subjectName is required, as does the > >>>> JSON OpenAPI. > >>>> > >>>> This got missed in earlier review because people (including myself) may > >>>> have been thinking about whether the parent object was present. > >>>> > >>>> Regards, > >>>> > >>>> Eliot > >>>> > >>>> > >>>> > >>>>> > >>>>> The AUTH48 status page for this document is available here: > >>>>> https://www.rfc-editor.org/auth48/rfc9944 > >>>>> > >>>>> — FILES (please refresh): — > >>>>> > >>>>> The updated files have been posted here: > >>>>> https://www.rfc-editor.org/authors/rfc9944.txt > >>>>> https://www.rfc-editor.org/authors/rfc9944.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9944.html > >>>>> https://www.rfc-editor.org/authors/rfc9944.xml > >>>>> > >>>>> Diff files showing changes between the last and current version: > >>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html > >>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by > >>>>> side) > >>>>> > >>>>> Diff files showing changes made during AUTH48: > >>>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side by > >>>>> side) > >>>>> > >>>>> Diff files showing all changes: > >>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) > >>>>> > >>>>> All best, > >>>>> > >>>>> Kaelin Foody > >>>>> RFC Production Center > >>>>> > >>>>>> On Apr 7, 2026, at 1:45 PM, Eliot Lear <[email protected]> wrote: > >>>>>> > >>>>>> Hi Kaelin > >>>>>> > >>>>>> Hassan identified a number of typos and omissions in his review. Some > >>>>>> of these will need IANA review, as there are several entries missing. > >>>>>> All of these, I think, are non-controversial edits. > >>>>>> > >>>>>> There is one exception that we will come back to after this one. It’s > >>>>>> not that it’s controversial, but it is a substantive change. > >>>>>> > >>>>>> Eliot > >>>>>> 1. Section 7.4.1, Figure 10 (FDO Example) — schema URIs in JSON > >>>>>> OLD: urn:ietf:params:scim:schemas:core:2.0:Devices and > >>>>>> urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices > >>>>>> NEW: urn:ietf:params:scim:schemas:core:2.0:Device and > >>>>>> urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device > >>>>>> 2. Appendix A.7, FDO Extension JSON Schema — id and meta.location use > >>>>>> plural "Devices" > >>>>>> OLD: "id": > >>>>>> "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices" > >>>>>> and "location": "...fido-device-onboard:2.0:Devices" > >>>>>> NEW: "id": > >>>>>> "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device" > >>>>>> and "location": "...fido-device-onboard:2.0:Device" > >>>>>> 3. Section 7.5.1, Zigbee deviceEui64Address description > >>>>>> OLD: "takes the same form as the deviceMACaddress" > >>>>>> NEW: "takes the same form as the deviceMacAddress " > >>>>>> 4. Section 7.6.2, description of $ref attribute > >>>>>> OLD: "EndointApp" > >>>>>> NEW: "EndpointApp" > >>>>>> 5. Appendix A.1, Resource Schema — EndpointApp endpoint path > >>>>>> OLD: "endpoint": "/EndpointApp" > >>>>>> NEW: "endpoint": "/EndpointApps" 6. OLD: "location": > >>>>>> "https://example.com/v2/ResourceTypes/EndpointApp";, > >>>>>> NEW: "location": "https://example.com/v2/ResourceTypes/EndpointApps";, > >>>>>> 7. Appendix A.3, EndpointApp Schema meta.location > >>>>>> OLD: "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Device" > >>>>>> NEW: "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:EndpointApp" > >>>>>> 8. Appendix A.4, in schema with ID > >>>>>> "urn:ietf:params:scim:schemas:extension:pairingOOB:2.0:Device", > >>>>>> OLD: "description": "Passkey pairing method for BLE." > >>>>>> NEW: "description": "Out-of-band pairing method for BLE." > >>>>>> 9. Appendix A.4, BLE Extension JSON Schema — mobility type > >>>>>> OLD: "type": "bool" > >>>>>> NEW: "type": "boolean" > >>>>>> 10. [We’ll come back to this one] > >>>>>> 11. Section 6.3.1, Table 2 — clientToken Return column > >>>>>> OLD: Return = N > >>>>>> New: Return = Def > >>>>>> 12. Section 7.1.3, Table 3 — isRandom Required column > >>>>>> OLD: Req = T > >>>>>> NEW: Req = F > >>>>>> 13. Section 7.2.1, prose description of bootstrapKey > >>>>>> OLD: "This attribute is required, case sensitive, mutable, and > >>>>>> returned by default." > >>>>>> NEW: "This attribute is required, case sensitive, write only, and > >>>>>> never returned." > >>>>>> 14. Section 9.2, IANA registrations for BLE pairing method extensions > >>>>>> (pairingNull) — missing entry > >>>>>> NEW: > >>>>>> Schema URI: > >>>>>> urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device > >>>>>> Name: Pairing Null > >>>>>> Resource Type: Device > >>>>>> Reference: RFC 9944, Section 7.1.3 > >>>>>> 15. Section 9.2, IANA registrations for Zigbee — missing entry > >>>>>> NEW: > >>>>>> Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device > >>>>>> Name: Zigbee > >>>>>> Resource Type: Device > >>>>>> Reference: RFC 9944, Section 7.5 > >>>>>> 16. Section 9.2, IANA registration for > >>>>>> urn:ietf:params:scim:schemas:extension:endpointAppsExt:2.0:Device — > >>>>>> Reference > >>>>>> OLD: RFC 9944, Section 7.1.3 > >>>>>> NEW: RFC 9944, Section 7.6 > >>>>>> 17. Appendix A.4, BLE Extension JSON Schema — irk mutability and > >>>>>> returned fields > >>>>>> OLD: "mutability": "readWrite", "returned": "default" > >>>>>> NEW: "mutability": "writeOnly", "returned": "never" > >>>>>> 18. Appendix A.4, pairingJustWorks schema — key attribute > >>>>>> OLD: "required": true > >>>>>> NEW: "required": false > >>>>>> 19. Appendix A.7, FDO Extension JSON Schema — fdoVoucher mutability > >>>>>> and returned fields > >>>>>> OLD: "mutability": "readWrite", "returned": "default" > >>>>>> NEW: "mutability": "writeOnly", "returned": "never" > >>>>>> 0a. Section 6.3.1, Table 2 — clientToken > >>>>>> For applicationType: > >>>>>> OLD: Mutable = R > >>>>>> NEW: Mutable = RO > >>>>>> 20b. Section 6.2, prose description of applicationType > >>>>>> OLD: "The attribute is required and is not case sensitive. The > >>>>>> attribute is readOnly and should be returned by default." > >>>>>> NEW: "The attribute is required and is not case sensitive. The > >>>>>> attribute is immutable and should be returned by default." > >>>>>> 20c. Section 6.3.1, Table 2 — applicationType Mutable column > >>>>>> OLD: Mutable = R > >>>>>> NEW: Mutable = Imm > >>>>>> 21. Section 7.6.2, Table 8 — devContEntEndpoint and telEntEndpoint > >>>>>> For devContEntEndpoint: > >>>>>> OLD: Mutable = R > >>>>>> NEW: Mutable = RO > >>>>>> For telEntEndpoint: > >>>>>> OLD: Mutable = R > >>>>>> NEW: Mutable = RO > >>>>>> 22. Section 7.6.1, prose description of deviceControlEnterpriseEndpoint > >>>>>> OLD: "This attribute is required, case sensitive, mutable, and > >>>>>> returned by default." > >>>>>> NEW: "This attribute is required, case sensitive, read-only, and > >>>>>> returned by default." > >>>>>> 23. Section 7.6.1, prose description of telemetryEnterpriseEndpoint > >>>>>> OLD: "This attribute is optional, case sensitive, mutable, and > >>>>>> returned by default." > >>>>>> NEW: "This attribute is optional, case sensitive, read-only, and > >>>>>> returned by default." > >>>>>> 24. Section 7.6.2, Table 8 — $ref > >>>>>> OLD: $ref row Case Exact = F > >>>>>> NEW: $ref row Case Exact = T > >>>>>> 25. Appendix A.5, DPP Extension Schema — bootstrapKey > >>>>>> OLD: "mutability": "readWrite", "returned": "default" > >>>>>> NEW: "mutability": "writeOnly", "returned": "never" > >>>>>> 26. [We’ll come back to this one] > >>>>>> 27. [deleted] > >>>>>> 28. Section 6.3.1, Table 2 — missing groups attribute row > >>>>>> OLD: (no groups row in Table 2) > >>>>>> NEW: Add row groups | T | F | T | RO | Def | n/a > >>>>>> 29. Appendix A.9, endpointAppsExt Extension Schema — $ref > >>>>>> sub-attribute required > >>>>>> OLD: "required": false > >>>>>> NEW: "required": true > >>>>>> 30. Section 7.1.3, prose — incorrect cross-reference to Section 6.1 > >>>>>> OLD: "Each extension contains the common attributes in Section 6.1." > >>>>>> NEW: "Each extension contains the common attributes in Section 2.1." > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> Best > >>> Hassan Iqbal > >> > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
