Материал: part07

Each Service Class specification is required to document, as part of its SOP Class or Meta SOP Class, the application information it​ supports and how this information is negotiated between SCUs and SCPs. Service Class specifications shall specify, for both the​ SCU and SCP roles, the following:​

•​semantics of the application information (including the negotiation rules)​

•​encoding of the application information​

•​conditions for which the application information is mandatory and/or optional​

•​default conditions of the application information​

Note​

The use of the SOP Class Extended Negotiation is not limited to Service Classes defined by this Standard. It may also be​ used for privately defined Service Classes.​

The Association-requester may only offer one SOP Class Extended Negotiation item for each SOP Class UID or Meta SOP Class​ that is present in the A-ASSOCIATE request.​

If the SOP Class Extended Negotiation items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE​ response.​

D.3.3.5.1 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)​

The SOP Class Extended Negotiation Sub-item shall be made of a sequence of mandatory fields followed by the Service-class-ap-​ plication-information field (specific for each Service Class specification). This Sub-Item is required per the specific Service Class​ specifications. Multiple SOP Class Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSOCIATE-RQ,​ however, only one Sub-Item per SOP Class UID shall be present. Table D.3-11 shows the sequence of mandatory fields.​

TableD.3-11.SOPClassExtendedNegotiationSub-ItemFields(A-ASSOCIATE-RQandA-ASSOCIATE-AC)​

D.3.3.5.2 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)​

The SOP Class Extended Negotiation Sub-item shall be made of a sequence of mandatory fields followed by the Service-class-ap-​ plication-information field (specific for each Service Class specification). This Sub-Item is required per the specific Service Class​ specifications. Multiple SOP Class Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSOCIATE-AC,​ however, only one Sub-Item per SOP Class UID shall be present. Table D.3-11 shows the sequence of mandatory fields.​

- Standard -​

D.3.3.6 Service-Object Pair (SOP) Class Common Extended Negotiation​

The SOP Class Common Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application in-​ formation, the form of which is generic, and not specific to individual Service Classes, as compared to the information defined in​ D.3.3.5. This is an optional feature that Association-requesters and Association-acceptors may or may not choose to support.​

TheinformationincludedforeachSOPClassforwhichasub-itemispresentconsistsofaServiceClassUIDand(optionally)aRelated​

General SOP Class UID.​

The Service Class UID conveys the Service Class of the SOP Class.​

Note​

Explicit conveyance of the Service Class may allow the selection of the proper format for the Service-class-application-in-​ formation of the SOP Class Extended Negotiation Sub-item.​

The Related General SOP Class UID conveys zero or more Related General SOP Class for the SOP Class.​

Note​

1.​Consider the example of negotiation of support for a Procedure Log Storage SOP Class. That SOP Class is of the​ Storage Service Class. The encoding of the IOD would be compatible with the more general Enhanced SR Storage​ SOP Class. Therefore, the following common extended negotiation sub-item could optionally be included:​

SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.40 Procedure Log​

Service Class UID: 1.2.840.10008.4.2 Storage Service Class​

Related General SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR​

2.​The Related SOP Class may be absent, though the Service Class may still be included. For example, there may be a​ new image storage SOP Class without a Related SOP Class defined in PS3.4, yet it is still useful to an Association-ac-​ ceptor to be informed that the new SOP Class is of the Storage Service Class:​

SOP Class UID: 1.2.840.10008.5.1.4.1.1.7.1 MF Single Bit SC Image Storage​

Service Class UID: 1.2.840.10008.4.2 Storage Service Class​

Related General SOP Class UID: (none)​

TheAssociation-requestermayonlyofferoneSOPClassCommonExtendedNegotiationitemforeachSOPClassUIDthatispresent​ in the A-ASSOCIATE request.​

Noresponseisnecessary,hencetheSOPClassCommonExtendedNegotiationitemsshallbeomittedintheA-ASSOCIATEresponse.​

D.3.3.6.1 SOP Class Common Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)​

The SOP Class Common Extended Negotiation Sub-item shall be made of a sequence of mandatory fields, the last two of which may​ be zero-length. Multiple SOP Class Common Extended Negotiation Sub-Items may be present in the User Data Item of the A-ASSO-​ CIATE-RQ, however, only one Sub-Item per SOP Class UID shall be present. Table D.3-12 shows the sequence of mandatory fields.​

Table D.3-12. SOP Class Common Extended Negotiation Sub-Item Fields (A-ASSOCIATE-RQ)​

affectthesemanticsofpreviouslydefinedfields.Theversionofthe​ Sub-item defined in this edition of the Standard is 0.​

- Standard -​

(y+1) - (y+2)​ Related-general-sop-class-identification-length​The Related-general-sop-class-identification-length shall be the​

Table D.3-13. Related-General-SOP-Class-Identification Sub-Fields​

D.3.3.7 User Identity Negotiation​

The User Identity Negotiation is used to notify the association acceptor of the user identity of the association requestor. It may also​ request that the association acceptor respond with the server identity. This negotiation is optional. If this sub-item is not present in​ the A-ASSOCIATE request the A-ASSOCIATE response shall not contain a user identity response sub-item.​

The Association-requester conveys in the A-ASSOCIATE request:​

•​the form of user identity being provided, either a username, username and passcode, a Kerberos service ticket, a SAML assertion,​ or a JSON Web Token (JWT).​

•​an indication whether a positive server response is requested.​

The Association-acceptor does not provide an A-ASSOCIATE response unless a positive response is requested and user authentic-​ ation succeeded. If a positive response was requested, the A-ASSOCIATE response shall contain a User Identity sub-item. If a Ker-​ beros ticket is used the response shall include a Kerberos server ticket.​

Since a system may ignore request sub-items, the positive response must be requested if the association requestor requires confirm-​ ation. If the association acceptor does not support user identification it will accept the association without making a positive response.​ The association requestor can then decide whether to proceed.​

The association acceptor may utilize the User Identity information provided during the association negotiation to populate the user​ information fields in DICOM audit trail messages. The association acceptor may utilize the User Identity information provided during​ the association negotiation to perform authorization controls during the performance of other DIMSE transactions on the same asso-​

- Standard -​

ciation. The user identity information may also be used to modify the performance of DIMSE transactions for other purposes, such​ as workflow optimizations.​

Note​

1.​User identity authorization controls may be simple "allow/disallow" rules, or they can be more complex scoping rules.​ For example, a query could be constrained to apply only to return information about patients that are associated with​ the identified user. The issues surrounding authorization controls can become very complex. The User Identity SOP​ conveysuseridentitytosupportusessuchasauthorizationcontrolsandauditcontrols.Itdoesnotspecifytheirbehavior.​

2.​The option to include a passcode along with the user identity enables a variety of non-Kerberos secure interfaces.​ Sending passwords in the clear is insecure, but there are single use password systems such as RFC-2289 and the​ varioussmarttokensthatdonotrequireprotection.ThepasswordmightalsobeprotectedbyTLSorothermechanisms.​

3.​ForJSONWebTokens(JWTs),RFC7519specifiesminimalrequirementsforencryption,MACandsignaturealgorithms;​ others may be supported as described in the DICOM Conformance Statement. The encoded format in the Primary-field​ of the A-ASSOCIATE-RQ is the same as what might be included in an HTTP Authorization: Bearer header field per​ RFC 6750 when accessing a Protected Resource on a Resource Server, to facilitate bridging between PS3.18 “PS3.18”​ and PS3.7 “PS3.7” implementations.​

DICOM AE “A”

DICOM AE “B”

User identification Sub-Item

Server Response

(58H)

Figure D.3-8. User Identity Negotiation (With Server Positive Response Requested)​

DICOM AE “A”

Figure D.3-9. User Identity Negotiation (Application Entity "A" Provides Username Identity)​ D.3.3.7.1 User Identity Sub-Item Structure (A-ASSOCIATE-RQ)​

The User Identity Negotiation Sub-Item shall be made of a sequence of mandatory fixed and variable length fields. This Sub-Item is​ optional and if supported, only one User Identity Negotiation Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-​ RQ. Table D.3-14 shows the sequence of the mandatory fields.​

- Standard -​

Page 120​ DICOM PS3.7 2020a - Message Exchange​

Table D.3-14. User Identity Negotiation Sub-Item Fields (A-ASSOCIATE-RQ)​

D.3.3.7.2 User Identity Sub-Item Structure (A-ASSOCIATE-AC)​

The User Identity Sub-Item shall be made of a sequence of mandatory fixed and variable length fields. This Sub-Item is optional and​ if supported, only one User Identity Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-AC. Table D.3-15 shows​ the sequence of the mandatory fields.​

Table D.3-15. User Identity Negotiation Sub-Item Fields (A-ASSOCIATE-AC)​

- Standard -​