# SMART Health Links: Historical Design

---
### Older design sketches below...

See historical archive.

#### Protocol Ideas

1. **OAuth Method**. Using extension on OAuth 2.0, where client registrations can be tied to a specific data access policyy
* Pros: Leverages existing healthcar domain expertise with OAuth 2.0 (SMART on FHIR)
* Cons: Requires new extension parameters, requires a flavor of dynamic registration
2. **Redirect Method**. Using simple URLs with redirects, where a QR includes a link that dereferences to content
* Pros: Very simple, easy to implement
* Cons: Doesn't support binding access to a Data Recipient's keys
3. **GNAP Method**. Using GNAP, a draft spec for IETF (roughly: an OAuth successor protocol with more flexible sharing when the resource owner and the end-user are different entities).
* Pros: this is in the sweet spot of GNAP's design space
* Cons: Protocol is not yet mature; no existing library support; complexity in GNAP's approach to binding the full contents of every request URL, method, and body to a cryptograph signature

#
Design Sketch #1: OAuth Method
See writeup at https://hackmd.io/qx2capMpSTSz488f8juf_A

---

Design Sketch #2: Redirect Method

See write-up at https://hackmd.io/qVo4lZB8SDy73rTPsWhKpQ

---

Design Sketch #3: GNAP Method

See writeup at https://hackmd.io/a7glQxowQayBl7ByDZI7kg

Design Questions

* Can we embed these payloads into `shc:/` existing format? e.g.

{
  "type": ["https://smarthealth.cards#health-card", "https://smarthealth.cards#shclink"],
  "shclink": [{
    "oauth": {
      "url": "https://labcorp.com",
      "token" :"opaque-string-128-bits"
    },
    "flags": "LOP",
    "decrypt": "43-chars-encoding-32-random-bytes-1234567890"
  }]
}

Out of scope notes re: reference implementation

Moved to a [separate file](https://hackmd.io/CAOYz9tFTjyR_oazYV5CFw)