Skip to main content

What are Attributes?

Attributes in boop network are pieces of information associated with a user that can be selectively shared with vendors during authentication. Unlike traditional systems, attributes are:

User-Controlled

Users decide what to share and with whom

Encrypted

All attributes are encrypted at rest

Consent-Based

Explicit consent required for each vendor

Types of Attributes

System Attributes

Managed by boop network:
AttributeDescriptionExample
user_idUnique identifieruuid-v4
registration_dateWhen user joined2024-01-01
palm_registeredWhich palms registered["left", "right"]
last_authLast authentication2024-01-15T10:30:00Z

User Attributes

Provided by users:
AttributeDescriptionValidation
emailEmail addressEmail format
phonePhone numberE.164 format
date_of_birthBirth dateDate format
postal_codePostal/ZIP codeCountry-specific

Verified Attributes

Verified by trusted third parties:
AttributeVerifierUse Case
age_verifiedGovernment ID serviceAge-restricted venues
identity_verifiedKYC providerFinancial services
membership_statusOrganizationMember benefits
vaccination_statusHealth authorityHealth requirements

Computed Attributes

Derived from other attributes:
# Example computed attributes
computed_attributes = {
    "is_adult": date_of_birth <= (today - 18_years),
    "is_senior": date_of_birth <= (today - 65_years),
    "loyalty_tier": calculate_tier(transaction_history),
    "risk_score": calculate_risk(auth_history)
}

Privacy Model

Selective Disclosure

Zero-Knowledge Proofs

For sensitive attributes, boop uses zero-knowledge proofs:
Vendors can verify attributes without seeing actual values. For example, proving “user is over 21” without revealing exact age.
# Zero-knowledge age verification
def verify_age_over_21(encrypted_dob, proof):
    """
    Verify user is over 21 without decrypting date of birth
    """
    # Verify proof that encrypted_dob represents age > 21
    return zkp_verify(
        statement="age >= 21",
        commitment=encrypted_dob,
        proof=proof
    )
{
  "consent_id": "con_abc123",
  "user_id": "usr_def456",
  "vendor_id": "ven_ghi789",
  "attributes": [
    {
      "name": "email",
      "purpose": "transaction_receipts",
      "retention_days": 30
    },
    {
      "name": "age_verified",
      "purpose": "compliance",
      "retention_days": 0  // Not stored by vendor
    }
  ],
  "granted_at": "2024-01-01T00:00:00Z",
  "expires_at": "2025-01-01T00:00:00Z",
  "revocable": true,
  "audit_log": true
}

Attribute Lifecycle

1

Creation

User provides attribute value
2

Validation

System validates format and constraints
3

Encryption

Attribute encrypted with user-specific key
4

Storage

Stored in attribute service database
5

Consent

User grants vendor access
6

Disclosure

Shared during authentication
7

Audit

Access logged for compliance
8

Expiry/Deletion

Removed per retention policy

API Operations

Setting Attributes

curl -X PUT https://api.boop.network/v1/attributes/email \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "value": "[email protected]",
    "encrypted": false
  }'
curl -X GET https://api.boop.network/v1/consents \
  -H "Authorization: Bearer USER_TOKEN"

Vendor Integration

Requesting Attributes

Vendors specify required and optional attributes:
{
  "auth_context": {
    "type": "payment",
    "amount": 2500,
    "attributes_required": [
      "email"  // Must have for receipt
    ],
    "attributes_optional": [
      "loyalty_status",  // For discounts
      "phone"  // For SMS notification
    ]
  }
}

Attribute Response

Vendor receives only consented attributes:
{
  "auth_result": {
    "success": true,
    "user_id": "usr_abc123",
    "attributes": {
      "email": "[email protected]",
      "loyalty_status": "gold"
      // phone not included - no consent
    },
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

Privacy Features

Attribute Minimization

Vendors should only request attributes necessary for their service. boop monitors and may restrict vendors requesting excessive attributes.

Pseudonymization

Users can have different identifiers per vendor:
def generate_vendor_specific_id(user_id, vendor_id):
    """
    Generate consistent but unique ID per vendor
    """
    return hmac_sha256(
        key=user_id,
        message=vendor_id
    )

Temporal Attributes

Some attributes auto-expire:
{
  "temporal_attributes": [
    {
      "name": "event_ticket",
      "value": "VIP_PASS_2024",
      "valid_from": "2024-06-01T00:00:00Z",
      "valid_until": "2024-06-03T23:59:59Z"
    },
    {
      "name": "promotion_eligible",
      "value": true,
      "valid_until": "2024-12-31T23:59:59Z"
    }
  ]
}

Compliance & Regulations

GDPR Compliance

Users can export all their attributes:
curl -X GET https://api.boop.network/v1/gdpr/export \
  -H "Authorization: Bearer USER_TOKEN"

Audit Logging

All attribute access is logged:
CREATE TABLE attribute_audit (
    id UUID PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL,
    user_id UUID NOT NULL,
    vendor_id UUID,
    attribute_name VARCHAR(50),
    operation VARCHAR(20), -- READ, UPDATE, DELETE
    ip_address INET,
    user_agent TEXT,
    result VARCHAR(20), -- SUCCESS, DENIED, ERROR
    INDEX idx_user_time (user_id, timestamp),
    INDEX idx_vendor_time (vendor_id, timestamp)
);

Advanced Features

Attribute Verification Chain

Federated Attributes

Import attributes from external identity providers:
class FederatedAttributeProvider:
    def import_from_oauth(self, provider, token):
        """
        Import attributes from OAuth provider
        """
        if provider == "google":
            profile = google_api.get_profile(token)
            return {
                "email": profile.email,
                "email_verified": profile.verified,
                "name": profile.name
            }
        elif provider == "government_id":
            identity = gov_api.verify_identity(token)
            return {
                "legal_name": identity.full_name,
                "date_of_birth": identity.dob,
                "identity_verified": True
            }

Attribute Analytics (Privacy-Preserving)

-- Aggregate analytics without individual tracking
SELECT 
    attribute_name,
    COUNT(DISTINCT vendor_id) as vendors_requesting,
    COUNT(*) as total_requests,
    AVG(CASE WHEN shared THEN 1 ELSE 0 END) as consent_rate
FROM attribute_requests
WHERE request_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY attribute_name
ORDER BY total_requests DESC;

Best Practices

For Users

  1. Review Regularly: Check which vendors have access
  2. Minimal Sharing: Only share necessary attributes
  3. Revoke Unused: Remove consent for unused services
  4. Verify Accuracy: Keep attributes up-to-date
  5. Use Pseudonyms: Where real names aren’t required

For Vendors

  1. Request Minimum: Only ask for essential attributes
  2. Explain Purpose: Clear explanation for each attribute
  3. Honor Expiry: Respect consent expiration
  4. Secure Storage: Encrypt received attributes
  5. Quick Deletion: Remove when no longer needed

For Developers

  1. Validate Input: Check attribute format/constraints
  2. Encrypt Everything: Never store plaintext attributes
  3. Audit Access: Log all attribute operations
  4. Handle Absence: Gracefully handle missing optional attributes
  5. Cache Wisely: Respect retention periods

Next Steps