Hi RFC Editor and chairs and AD: In operational practice we have noticed two issues we would like to address in the RFC before it is closed. The first has to do with the use of OAUTH as a means to authenticate SCIM connections. Today we say in Section 6.3.1:
OLD: > Note that either clientToken or certificateInfo is used for the > authentication of the application. If certificateInfo is NOT present when an > endpointApp object is created, then the server SHOULD return a clientToken. > Otherwise, if the server accepts the certificateInfo object for > authentication, it SHOULD NOT return a clientToken. If the server accepts and > produces a clientToken, then control and telemetry servers MUST validate > both. The SCIM client will know that this is the case based on the SCIM > object that is returned. Now there’s a nice big SHOULD in the middle of that, but it leads to a question as to when that SHOULD doesn’t apply. The obvious answer is with OAUTH. So we think the following text would address that point: NEW: > If certificateInfo is provided by the client and is accepted by the server, > the server MUST return that multivalued attribute in its response. > Otherwise, the server is expected to return a clientToken. If the server > returns neither certificateInfo nor a clientToken, then external > authentication such as [OAUTHv2] MUST be pre-arranged. If the server accepts > a certificate and produces a clientToken, then control and telemetry servers > MUST validate both. This is a bit more crisp and prescriptive. Then in Section 7.6.1, we’ve noted one other issue: > telemetryEnterpriseEndpoint: > A string representing a URL of the enterprise endpoint to reach an enterprise > gateway for telemetry. When the enterprise receives the SCIM object from the > onboarding application, it adds this attribute to it and sends it back as a > response to the onboarding application. This attribute is optional, case > sensitive, mutable, and returned by default. The uniqueness is enforced by > the enterprise. An implementation MUST generate an exception if > telemetryEnterpriseEndpoint is not returned and telemetry is required for the > proper functioning of a device. > It is possible that this service may be externalized. That is, it’s there, but the SCIM implementation for $REASONs doesn’t know about it. To address this point, we propose to replace the last sentence (“An implementation … a device.”) as follows: NEW: > This attribute is populated when the enterprise provides a telemetry endpoint > (e.g., hosted by the enterprise gateway). If a telemetry service is not > known by the SCIM server, the attribute will not be returned. In such cases, > if the application requires telemetry, separate arrangements must be made. Two other points: To answer Kaelin’s earlier question, we propose to add a note in Section 1.3 as follows: > When JSON is presented in this memo, it is folded in accordance with RFC 8792. Also, we caught one error in an example in Section 7.6.2. OLD: > "telemetryEnterpriseEndpoint": "https://example.com/\ NEW: > "telemetryEnterpriseEndpoint": "mqtts://example.com/\ Noting the change of URI scheme. Finally, these matters were brought to our attention by Sriram Sekar who I would ask to be added to the acknowledgments. Eliot > On 11 Mar 2026, at 19:39, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2026/03/11 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9944.xml > https://www.rfc-editor.org/authors/rfc9944.html > https://www.rfc-editor.org/authors/rfc9944.pdf > https://www.rfc-editor.org/authors/rfc9944.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9944-diff.html > https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9944-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9944 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9944 (draft-ietf-scim-device-model-18) > > Title : Device Schema Extensions to the SCIM model > Author(s) : M. Shahzad, H. Iqbal, E. Lear > WG Chair(s) : Nancy Cam-Winget > Area Director(s) : Deb Cooley, Paul Wouters > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
