|
| 1 | +--- |
| 2 | +CIP: /? |
| 3 | +Title: Role based Access Control Registration |
| 4 | +Category: MetaData |
| 5 | +Status: Proposed |
| 6 | +Authors: |
| 7 | + - Steven Johnson<[email protected]> |
| 8 | +Implementors: [] |
| 9 | +Discussions: |
| 10 | + - https://github.com/cardano-foundation/cips/pulls/? |
| 11 | +Created: 2023-10-24 |
| 12 | +License: CC-BY-4.0 |
| 13 | +--- |
| 14 | + |
| 15 | +<!-- Existing categories: |
| 16 | + |
| 17 | +- Meta | For meta-CIPs which typically serves another category or group of categories. |
| 18 | +- Wallets | For standardization across wallets (hardware, full-node or light). |
| 19 | +- Tokens | About tokens (fungible or non-fungible) and minting policies in general. |
| 20 | +- Metadata | For proposals around metadata (on-chain or off-chain). |
| 21 | +- Tools | A broad category for ecosystem tools not falling into any other category. |
| 22 | +- Plutus | Changes or additions to Plutus |
| 23 | +- Ledger | For proposals regarding the Cardano ledger (including Reward Sharing Schemes) |
| 24 | +- Catalyst | For proposals affecting Project Catalyst / the Jormungandr project |
| 25 | + |
| 26 | +--> |
| 27 | + |
| 28 | +<!-- markdownlint-disable MD025--> |
| 29 | +# Role Based Access Control Registration |
| 30 | + |
| 31 | +## Abstract |
| 32 | +<!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. --> |
| 33 | + |
| 34 | +## Motivation: why is this CIP necessary? |
| 35 | +<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. |
| 36 | +If the CIP changes an established design then it must outline design issues that motivate a rework. |
| 37 | +For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 |
| 38 | +and link to it as the `Motivation`. --> |
| 39 | + |
| 40 | +## Specification |
| 41 | +<!-- The technical specification should describe the proposed improvement in sufficient technical detail. |
| 42 | +In particular, it should provide enough information that an implementation can be performed solely on the basis |
| 43 | +of the design in the CIP. |
| 44 | +This is necessary to facilitate multiple, interoperable implementations. |
| 45 | +This must include how the CIP should be versioned. |
| 46 | +If a proposal defines structure of on-chain data it must include a CDDL schema in it's specification.--> |
| 47 | + |
| 48 | +## Rationale: how does this CIP achieve its goals? |
| 49 | +<!-- The rationale fleshes out the specification by describing what motivated the design and what led to |
| 50 | +particular design decisions. |
| 51 | +It should describe alternate designs considered and related work. |
| 52 | +The rationale should provide evidence of consensus within the community and discuss significant objections |
| 53 | +or concerns raised during the discussion. |
| 54 | + |
| 55 | +It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. |
| 56 | +If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, |
| 57 | +and answer any questions that the CPS poses for potential solutions. |
| 58 | +--> |
| 59 | + |
| 60 | +## Path to Active |
| 61 | + |
| 62 | +### Acceptance Criteria |
| 63 | +<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' --> |
| 64 | + |
| 65 | +### Implementation Plan |
| 66 | +<!-- A plan to meet those criteria. Or `N/A` if not applicable. --> |
| 67 | + |
| 68 | +## Copyright |
| 69 | +<!-- The CIP must be explicitly licensed under acceptable copyright terms. --> |
0 commit comments