You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A client wishes to attest with an origin that they hold something of value, maybe a subscription. To implement this in PATs there are two obvious routes:
Allow the attester and origin to be the same entity. Attester can directly check for the clients subscription credentials
Allow the client to pass some extra (blind?) signed value that indicates to the issuer they meet the appropriate criteria. Maybe the client got this from the origin before engaging in the PATs protocol.
Note I am assuming most origins wouldn't store traits like subscriptions directly with attesters, although some platforms could support this.
Which route to go here isn't obvious to me. (1) has a simpler flow, but requires many origins to also become attesters. (2) may require less overall changes to the architecture, but may also be adding an entity, the 3P attester, that isn't really needed for this use case.
The text was updated successfully, but these errors were encountered:
A client wishes to attest with an origin that they hold something of value, maybe a subscription. To implement this in PATs there are two obvious routes:
Note I am assuming most origins wouldn't store traits like subscriptions directly with attesters, although some platforms could support this.
Which route to go here isn't obvious to me. (1) has a simpler flow, but requires many origins to also become attesters. (2) may require less overall changes to the architecture, but may also be adding an entity, the 3P attester, that isn't really needed for this use case.
The text was updated successfully, but these errors were encountered: