@@ -192,6 +192,34 @@ <h1>Introduction</h1>
192192 is being thoroughly discussed by the community. For example, see
193193 < a href ="https://github.com/w3c/did-spec/issues/166#issuecomment-464502719 "> this comment</ a > .</ p >
194194
195+ < section id ="design-goals ">
196+ < h2 > Design Goals and Rationale</ h2 >
197+ < p > < b > How DID resolution is used to address the needs from Software Developers:</ b > </ p >
198+ < p >
199+ By invoking a < a > DID resolver</ a > using the standard < code > resolve(did, resolutionOptions)</ code > interface (as defined in
200+ the < a href ="#resolving "> DID Resolution section</ a > ) one can obtain a < a > DID Document</ a > and accompanying metadata
201+ (e.g. contentType, proof, versioning) which an application can use to validate a user's cryptographic keys,
202+ service endpoints, or status.
203+ < p >
204+ For example, a wallet app could resolve < code > did:example:123?versionTime=2021-05-10T17:00:00Z</ code >
205+ (using the versionTime parameter) to retrieve the state of that DID at a past time, or a client could
206+ dereference a DID URL
207+ like < code > did:example:123?service=files&relativeRef=/resume.pdf</ code >
208+ (see < a href ="#example-dereferencing-to-service-endpoint-url "> here for detailed example</ a > )
209+ to fetch a user's resume stored via a service declared in the DID Document.
210+ </ p >
211+ < p >
212+ Further, the specification's < a href ="#dereferencing-algorithm "> DID URL dereferencing algorithm</ a > shows how
213+ a client can follow a fragment (e.g. < code > #key-1</ code > ) to extract a particular verification method from
214+ the < a > DID Document</ a > (see < a href ="#example-dereferencing-to-verification-method "> here for detailed example</ a > ).
215+ In practice, implementers validate their resolver against the
216+ < a href ="https://github.com/w3c-ccg/did-resolution-test-suite "> DID Resolution Test Suite</ a > which exercises
217+ normative MUST and error conditions (such as invalid DIDs, deactivated DIDs, unsupported methods,
218+ relative URL expansion, etc.) to ensure client applications can reliably depend on correct resolution behavior
219+ across different DID methods.
220+ </ p >
221+ </ section >
222+
195223 < section id ="conformance ">
196224
197225 < p >
0 commit comments