Provider contracts are explicit and provider credentials stay distinct.

Apple Account#

Apple Account automation uses a login item for the account email and password, plus a separate pending `challenge:apple/<authorization-id>` capability for the trusted-device code. All three capabilities are issued on the Weles execution host and can be consumed only by the authorization that requested them.

Apple's Developer ID trajectory is an Account Holder workflow coordinated by Stado and Weles. Skarbiec supplies finite credential capabilities and the pending challenge; the authorizer returns the private key and issued certificate to caller-named files without giving the runner a standing Account Holder password.

Microsoft Account#

The `microsoft` lifecycle contract manages a password bound to one exact account email. Acquire, rotate, reset, verify, and remove operations keep that account identity with the operation record rather than accepting a different account from a later caller.

Microsoft Entra#

The `microsoft_entra` lifecycle contract is bound to a sealed directory identity: provider, tenant UUID, principal object UUID, and account UPN. Lifecycle requests read that identity from the item; callers cannot replace it in an operation request.

skarbiec credential seal-directory <item-id> \
  --provider microsoft_entra \
  --tenant <tenant-uuid> \
  --object-id <principal-object-uuid> \
  --account-upn <account-upn>

Generic HTTPS providers#

Every other provider uses the generic acquisition contract: a lowercase provider slug, one `api_key` field, and an exact lowercase HTTPS signup origin. The item id defaults to the provider slug when acquire creates a credential that does not exist yet.

Generic does not mean automatically supported. The Weles lifecycle bridge must register and complete that provider trajectory. Unsupported providers fail without writing an item; a route or grant alone does not manufacture provider support.

skarbiec credential acquire <provider-slug> \
  --provider <provider-slug> \
  --consumer <consumer> \
  --purpose "<why it is needed>" \
  --signup-origin https://<provider-origin>

Provider credential items#

• Exact provider resources use `provider:<provider>:<account-or-subscription>` item ids. A provider's selected default ends in `-primary`; more than one primary is rejected as ambiguous.
• Provider items carry one canonical credential field such as `api_key` or `token`. Route reconciliation maps the resource to that exact item and field; it does not parse a provider name into broad vault access.
• Providers remain separate items. Rotating one provider cannot overwrite another provider's credential or change another consumer's grant.