{"owner":"openid","repo":"AppAuth-iOS","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":1328,"categories":["project-spec"],"hasMcp":false,"mcpConfig":null,"found":["DESIGN.md"],"skills":{"DESIGN.md":"# AppAuth Project Design Principles\n\n## About this Doc\n\nThe goal of this doc is to define a scope for AppAuth that we can reference when rejecting or\naccepting feature requests, and give clarity to extension creators for what features should be\ndeveloped outside of the core project.\n\n## What is AppAuth\n\n### OAuth and OpenID Connect standards that support native apps\n\nThe goal of AppAuth is to provide a client library that follows best current practices for native\napps to use the OAuth and OpenID Connect authorization and authentication standards. We aim to\nimplement standards that are designed for, or work well with native apps and are in common use (and\nwill implement just those components of these standards that are commonly used).\n\nThese standards are currently supported:\n1. [OAuth 2.0](https://tools.ietf.org/html/rfc67490)\n2. [Proof Key for Code Exchange by OAuth Public Clients (PKCE)](https://tools.ietf.org/html/rfc7636)\n3. [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252)\n4. [OpenID Connect Core 1.0](http://openid.net/specs/openid-connect-core-1_0.html)\n5. [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)\n6. [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html)\n\nSupport for the following standards is also considered in-scope (see the below section on\nprioritization):\n1. [OAuth 2.0 Incremental Auth](https://tools.ietf.org/html/draft-ietf-oauth-incremental-auth)\n2. [OAuth 2.0 Device Flow for Browserless and Input Constrained Devices](https://tools.ietf.org/html/rfc8628)\n3. [OpenID Connect Front-Channel Logout 1.0](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n\n### Design Principle\n\nAppAuth aims to present as close to a 1:1 mapping of the spec as is possible, while following\nlanguage-specific idioms (like parameter capitalization). It performs some of the heavy lifting for\nyou so you don’t need to implement the spec yourself, but it does not hide the complexity of the\nunderlying specs.\n\nProviders who want extremely simple user-friendly libraries aimed at developers who know nothing\nabout authorization and authentication standards are encouraged to wrap AppAuth in their own\npurpose-built libraries.\n\n### Extensibility\n\nAppAuth aims to be as extensible as possible. Just as you can extend OAuth by adding parameters to a\nURL (for example), the same should be possible in AppAuth.\n\nThis helps reduce the surface area of the library, as not everything needs to be hardcoded in as a\nfirst-class citizen.\n\n## What is out-of-scope for AppAuth\n\n### Non-best-practice patterns\n\nAppAuth is a best-practice library, it’s why we built it. We will not support things like embedded\nWebViews, that are not considered a best practice. Please don’t ask.\n\n### Implementing *every* spec parameter or branch\n\nAppAuth exposes some required and popular parameters directly in its data model. It is a non-goal to\noffer this support for every single parameter in the specifications. Less popular parameters, or\nones that simply don’t need special handling can be passed using the “additionalParameters” dictionary. \n\nLikewise, some specifications document several different sub-protocols. We don’t aim to implement\nevery single branch of the spec.\n\n### Non-standard protocols and parameters\n\nNon-standard protocols and parameters are not supported by AppAuth.  However, AppAuth, like the\nspecs it implements, is largely extensible and you may be able to achieve what you need through\nthese extension points. For example, simple additional parameters can be passed in the\n“additionalParameters” dictionary, and the TokenRequest can support other grant types. \n\nBy way of example, the tvOS device flow support (which may actually be considered in-scope one day)\nwas initially implemented on top of these extension points without needing to change AppAuth.\n\n### Provider-specific workarounds, hacks or features\n\nAppAuth implements the pure authentication and authorization standards. Where these standards are\nclear in their meaning, errors in provider implementations are not supported or worked around by\nAppAuth.  \n\nIdentity standards are well specified, and typically undergo years of review, including security\nreview before publication. If we accept every provider-specific idiosyncrasy then we are changing\nthe surface area in ways that are harder to maintain, and are less researched from a security\nperspective.  There is generally no reason providers can’t offer correct standards-based\nimplementations, so this is what we expect.\n\nWhen all providers follow the standards correctly, interoperability is improved for everyone. The\nOpenID Connect foundation has been particularly active in supporting certification efforts to verify\nimplementations, and the test suits for these are available at no charge.\n\nIf the spec itself has a bug that cannot be worked around, then changes should be proposed through\nthe IETF and/or OpenID Foundation channels. AppAuth may implement such proposals, even while they\nare in the early stages, if they are well received.\n\n### Provider-specific examples\n\nAs AppAuth is pure standards-based, there is no need for provider-specific samples. Instead, we\nencourage providers who have proved their compliance with the relevant standards to provide a\ncustomized readme so their users can configure their own samples.\n\nWe also encourage providers to host their own AppAuth samples, in their own repositories.\n\n## A word on feature requests\n\n### Priorities\n\nJust because something is in-scope, does not mean that the maintainers of AppAuth will add support\nfor it, or rapidly integrate pull requests.\n\nThe priority of AppAuth is stability and quality, not rapidly integrating feature requests. Pull\nrequests are thoroughly reviewed for style, the quality of the API, and future maintainability.\n\n### Review Time\n\nExpect review periods of 6 months to a year for integrating major new in-scope features. Our\npriority as previously stated is stability and quality, not adding features as quickly as possible.\nWhile you work with us to integrate your feature, we highly encourage you to maintain your own fork\nso you and others can use the feature immediately – and gain valuable implementation experience.\n"},"files":{"DESIGN.md":"# AppAuth Project Design Principles\n\n## About this Doc\n\nThe goal of this doc is to define a scope for AppAuth that we can reference when rejecting or\naccepting feature requests, and give clarity to extension creators for what features should be\ndeveloped outside of the core project.\n\n## What is AppAuth\n\n### OAuth and OpenID Connect standards that support native apps\n\nThe goal of AppAuth is to provide a client library that follows best current practices for native\napps to use the OAuth and OpenID Connect authorization and authentication standards. We aim to\nimplement standards that are designed for, or work well with native apps and are in common use (and\nwill implement just those components of these standards that are commonly used).\n\nThese standards are currently supported:\n1. [OAuth 2.0](https://tools.ietf.org/html/rfc67490)\n2. [Proof Key for Code Exchange by OAuth Public Clients (PKCE)](https://tools.ietf.org/html/rfc7636)\n3. [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252)\n4. [OpenID Connect Core 1.0](http://openid.net/specs/openid-connect-core-1_0.html)\n5. [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)\n6. [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html)\n\nSupport for the following standards is also considered in-scope (see the below section on\nprioritization):\n1. [OAuth 2.0 Incremental Auth](https://tools.ietf.org/html/draft-ietf-oauth-incremental-auth)\n2. [OAuth 2.0 Device Flow for Browserless and Input Constrained Devices](https://tools.ietf.org/html/rfc8628)\n3. [OpenID Connect Front-Channel Logout 1.0](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n\n### Design Principle\n\nAppAuth aims to present as close to a 1:1 mapping of the spec as is possible, while following\nlanguage-specific idioms (like parameter capitalization). It performs some of the heavy lifting for\nyou so you don’t need to implement the spec yourself, but it does not hide the complexity of the\nunderlying specs.\n\nProviders who want extremely simple user-friendly libraries aimed at developers who know nothing\nabout authorization and authentication standards are encouraged to wrap AppAuth in their own\npurpose-built libraries.\n\n### Extensibility\n\nAppAuth aims to be as extensible as possible. Just as you can extend OAuth by adding parameters to a\nURL (for example), the same should be possible in AppAuth.\n\nThis helps reduce the surface area of the library, as not everything needs to be hardcoded in as a\nfirst-class citizen.\n\n## What is out-of-scope for AppAuth\n\n### Non-best-practice patterns\n\nAppAuth is a best-practice library, it’s why we built it. We will not support things like embedded\nWebViews, that are not considered a best practice. Please don’t ask.\n\n### Implementing *every* spec parameter or branch\n\nAppAuth exposes some required and popular parameters directly in its data model. It is a non-goal to\noffer this support for every single parameter in the specifications. Less popular parameters, or\nones that simply don’t need special handling can be passed using the “additionalParameters” dictionary. \n\nLikewise, some specifications document several different sub-protocols. We don’t aim to implement\nevery single branch of the spec.\n\n### Non-standard protocols and parameters\n\nNon-standard protocols and parameters are not supported by AppAuth.  However, AppAuth, like the\nspecs it implements, is largely extensible and you may be able to achieve what you need through\nthese extension points. For example, simple additional parameters can be passed in the\n“additionalParameters” dictionary, and the TokenRequest can support other grant types. \n\nBy way of example, the tvOS device flow support (which may actually be considered in-scope one day)\nwas initially implemented on top of these extension points without needing to change AppAuth.\n\n### Provider-specific workarounds, hacks or features\n\nAppAuth implements the pure authentication and authorization standards. Where these standards are\nclear in their meaning, errors in provider implementations are not supported or worked around by\nAppAuth.  \n\nIdentity standards are well specified, and typically undergo years of review, including security\nreview before publication. If we accept every provider-specific idiosyncrasy then we are changing\nthe surface area in ways that are harder to maintain, and are less researched from a security\nperspective.  There is generally no reason providers can’t offer correct standards-based\nimplementations, so this is what we expect.\n\nWhen all providers follow the standards correctly, interoperability is improved for everyone. The\nOpenID Connect foundation has been particularly active in supporting certification efforts to verify\nimplementations, and the test suits for these are available at no charge.\n\nIf the spec itself has a bug that cannot be worked around, then changes should be proposed through\nthe IETF and/or OpenID Foundation channels. AppAuth may implement such proposals, even while they\nare in the early stages, if they are well received.\n\n### Provider-specific examples\n\nAs AppAuth is pure standards-based, there is no need for provider-specific samples. Instead, we\nencourage providers who have proved their compliance with the relevant standards to provide a\ncustomized readme so their users can configure their own samples.\n\nWe also encourage providers to host their own AppAuth samples, in their own repositories.\n\n## A word on feature requests\n\n### Priorities\n\nJust because something is in-scope, does not mean that the maintainers of AppAuth will add support\nfor it, or rapidly integrate pull requests.\n\nThe priority of AppAuth is stability and quality, not rapidly integrating feature requests. Pull\nrequests are thoroughly reviewed for style, the quality of the API, and future maintainability.\n\n### Review Time\n\nExpect review periods of 6 months to a year for integrating major new in-scope features. Our\npriority as previously stated is stability and quality, not adding features as quickly as possible.\nWhile you work with us to integrate your feature, we highly encourage you to maintain your own fork\nso you and others can use the feature immediately – and gain valuable implementation experience.\n"},"items":[{"name":"DESIGN.md","path":"DESIGN.md","rawUrl":"https://raw.githubusercontent.com/openid/AppAuth-iOS/HEAD/DESIGN.md","title":"UI Design System & Style Tokens","category":"project-spec","format":"markdown","content":"# AppAuth Project Design Principles\n\n## About this Doc\n\nThe goal of this doc is to define a scope for AppAuth that we can reference when rejecting or\naccepting feature requests, and give clarity to extension creators for what features should be\ndeveloped outside of the core project.\n\n## What is AppAuth\n\n### OAuth and OpenID Connect standards that support native apps\n\nThe goal of AppAuth is to provide a client library that follows best current practices for native\napps to use the OAuth and OpenID Connect authorization and authentication standards. We aim to\nimplement standards that are designed for, or work well with native apps and are in common use (and\nwill implement just those components of these standards that are commonly used).\n\nThese standards are currently supported:\n1. [OAuth 2.0](https://tools.ietf.org/html/rfc67490)\n2. [Proof Key for Code Exchange by OAuth Public Clients (PKCE)](https://tools.ietf.org/html/rfc7636)\n3. [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252)\n4. [OpenID Connect Core 1.0](http://openid.net/specs/openid-connect-core-1_0.html)\n5. [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)\n6. [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html)\n\nSupport for the following standards is also considered in-scope (see the below section on\nprioritization):\n1. [OAuth 2.0 Incremental Auth](https://tools.ietf.org/html/draft-ietf-oauth-incremental-auth)\n2. [OAuth 2.0 Device Flow for Browserless and Input Constrained Devices](https://tools.ietf.org/html/rfc8628)\n3. [OpenID Connect Front-Channel Logout 1.0](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n\n### Design Principle\n\nAppAuth aims to present as close to a 1:1 mapping of the spec as is possible, while following\nlanguage-specific idioms (like parameter capitalization). It performs some of the heavy lifting for\nyou so you don’t need to implement the spec yourself, but it does not hide the complexity of the\nunderlying specs.\n\nProviders who want extremely simple user-friendly libraries aimed at developers who know nothing\nabout authorization and authentication standards are encouraged to wrap AppAuth in their own\npurpose-built libraries.\n\n### Extensibility\n\nAppAuth aims to be as extensible as possible. Just as you can extend OAuth by adding parameters to a\nURL (for example), the same should be possible in AppAuth.\n\nThis helps reduce the surface area of the library, as not everything needs to be hardcoded in as a\nfirst-class citizen.\n\n## What is out-of-scope for AppAuth\n\n### Non-best-practice patterns\n\nAppAuth is a best-practice library, it’s why we built it. We will not support things like embedded\nWebViews, that are not considered a best practice. Please don’t ask.\n\n### Implementing *every* spec parameter or branch\n\nAppAuth exposes some required and popular parameters directly in its data model. It is a non-goal to\noffer this support for every single parameter in the specifications. Less popular parameters, or\nones that simply don’t need special handling can be passed using the “additionalParameters” dictionary. \n\nLikewise, some specifications document several different sub-protocols. We don’t aim to implement\nevery single branch of the spec.\n\n### Non-standard protocols and parameters\n\nNon-standard protocols and parameters are not supported by AppAuth.  However, AppAuth, like the\nspecs it implements, is largely extensible and you may be able to achieve what you need through\nthese extension points. For example, simple additional parameters can be passed in the\n“additionalParameters” dictionary, and the TokenRequest can support other grant types. \n\nBy way of example, the tvOS device flow support (which may actually be considered in-scope one day)\nwas initially implemented on top of these extension points without needing to change AppAuth.\n\n### Provider-specific workarounds, hacks or features\n\nAppAuth implements the pure authentication and authorization standards. Where these standards are\nclear in their meaning, errors in provider implementations are not supported or worked around by\nAppAuth.  \n\nIdentity standards are well specified, and typically undergo years of review, including security\nreview before publication. If we accept every provider-specific idiosyncrasy then we are changing\nthe surface area in ways that are harder to maintain, and are less researched from a security\nperspective.  There is generally no reason providers can’t offer correct standards-based\nimplementations, so this is what we expect.\n\nWhen all providers follow the standards correctly, interoperability is improved for everyone. The\nOpenID Connect foundation has been particularly active in supporting certification efforts to verify\nimplementations, and the test suits for these are available at no charge.\n\nIf the spec itself has a bug that cannot be worked around, then changes should be proposed through\nthe IETF and/or OpenID Foundation channels. AppAuth may implement such proposals, even while they\nare in the early stages, if they are well received.\n\n### Provider-specific examples\n\nAs AppAuth is pure standards-based, there is no need for provider-specific samples. Instead, we\nencourage providers who have proved their compliance with the relevant standards to provide a\ncustomized readme so their users can configure their own samples.\n\nWe also encourage providers to host their own AppAuth samples, in their own repositories.\n\n## A word on feature requests\n\n### Priorities\n\nJust because something is in-scope, does not mean that the maintainers of AppAuth will add support\nfor it, or rapidly integrate pull requests.\n\nThe priority of AppAuth is stability and quality, not rapidly integrating feature requests. Pull\nrequests are thoroughly reviewed for style, the quality of the API, and future maintainability.\n\n### Review Time\n\nExpect review periods of 6 months to a year for integrating major new in-scope features. Our\npriority as previously stated is stability and quality, not adding features as quickly as possible.\nWhile you work with us to integrate your feature, we highly encourage you to maintain your own fork\nso you and others can use the feature immediately – and gain valuable implementation experience.\n","isInternal":false,"tokens":1328,"sizeBytes":6304}],"systemPromptSnippet":"<yakaai_skills repo=\"openid/AppAuth-iOS\">\n<!-- File: DESIGN.md (Tokens: ~1328 | Category: project-spec) -->\n# AppAuth Project Design Principles\n\n## About this Doc\n\nThe goal of this doc is to define a scope for AppAuth that we can reference when rejecting or\naccepting feature requests, and give clarity to extension creators for what features should be\ndeveloped outside of the core project.\n\n## What is AppAuth\n\n### OAuth and OpenID Connect standards that support native apps\n\nThe goal of AppAuth is to provide a client library that follows best current practices for native\napps to use the OAuth and OpenID Connect authorization and authentication standards. We aim to\nimplement standards that are designed for, or work well with native apps and are in common use (and\nwill implement just those components of these standards that are commonly used).\n\nThese standards are currently supported:\n1. [OAuth 2.0](https://tools.ietf.org/html/rfc67490)\n2. [Proof Key for Code Exchange by OAuth Public Clients (PKCE)](https://tools.ietf.org/html/rfc7636)\n3. [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252)\n4. [OpenID Connect Core 1.0](http://openid.net/specs/openid-connect-core-1_0.html)\n5. [Open ID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)\n6. [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html)\n\nSupport for the following standards is also considered in-scope (see the below section on\nprioritization):\n1. [OAuth 2.0 Incremental Auth](https://tools.ietf.org/html/draft-ietf-oauth-incremental-auth)\n2. [OAuth 2.0 Device Flow for Browserless and Input Constrained Devices](https://tools.ietf.org/html/rfc8628)\n3. [OpenID Connect Front-Channel Logout 1.0](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n\n### Design Principle\n\nAppAuth aims to present as close to a 1:1 mapping of the spec as is possible, while following\nlanguage-specific idioms (like parameter capitalization). It performs some of the heavy lifting for\nyou so you don’t need to implement the spec yourself, but it does not hide the complexity of the\nunderlying specs.\n\nProviders who want extremely simple user-friendly libraries aimed at developers who know nothing\nabout authorization and authentication standards are encouraged to wrap AppAuth in their own\npurpose-built libraries.\n\n### Extensibility\n\nAppAuth aims to be as extensible as possible. Just as you can extend OAuth by adding parameters to a\nURL (for example), the same should be possible in AppAuth.\n\nThis helps reduce the surface area of the library, as not everything needs to be hardcoded in as a\nfirst-class citizen.\n\n## What is out-of-scope for AppAuth\n\n### Non-best-practice patterns\n\nAppAuth is a best-practice library, it’s why we built it. We will not support things like embedded\nWebViews, that are not considered a best practice. Please don’t ask.\n\n### Implementing *every* spec parameter or branch\n\nAppAuth exposes some required and popular parameters directly in its data model. It is a non-goal to\noffer this support for every single parameter in the specifications. Less popular parameters, or\nones that simply don’t need special handling can be passed using the “additionalParameters” dictionary. \n\nLikewise, some specifications document several different sub-protocols. We don’t aim to implement\nevery single branch of the spec.\n\n### Non-standard protocols and parameters\n\nNon-standard protocols and parameters are not supported by AppAuth.  However, AppAuth, like the\nspecs it implements, is largely extensible and you may be able to achieve what you need through\nthese extension points. For example, simple additional parameters can be passed in the\n“additionalParameters” dictionary, and the TokenRequest can support other grant types. \n\nBy way of example, the tvOS device flow support (which may actually be considered in-scope one day)\nwas initially implemented on top of these extension points without needing to change AppAuth.\n\n### Provider-specific workarounds, hacks or features\n\nAppAuth implements the pure authentication and authorization standards. Where these standards are\nclear in their meaning, errors in provider implementations are not supported or worked around by\nAppAuth.  \n\nIdentity standards are well specified, and typically undergo years of review, including security\nreview before publication. If we accept every provider-specific idiosyncrasy then we are changing\nthe surface area in ways that are harder to maintain, and are less researched from a security\nperspective.  There is generally no reason providers can’t offer correct standards-based\nimplementations, so this is what we expect.\n\nWhen all providers follow the standards correctly, interoperability is improved for everyone. The\nOpenID Connect foundation has been particularly active in supporting certification efforts to verify\nimplementations, and the test suits for these are available at no charge.\n\nIf the spec itself has a bug that cannot be worked around, then changes should be proposed through\nthe IETF and/or OpenID Foundation channels. AppAuth may implement such proposals, even while they\nare in the early stages, if they are well received.\n\n### Provider-specific examples\n\nAs AppAuth is pure standards-based, there is no need for provider-specific samples. Instead, we\nencourage providers who have proved their compliance with the relevant standards to provide a\ncustomized readme so their users can configure their own samples.\n\nWe also encourage providers to host their own AppAuth samples, in their own repositories.\n\n## A word on feature requests\n\n### Priorities\n\nJust because something is in-scope, does not mean that the maintainers of AppAuth will add support\nfor it, or rapidly integrate pull requests.\n\nThe priority of AppAuth is stability and quality, not rapidly integrating feature requests. Pull\nrequests are thoroughly reviewed for style, the quality of the API, and future maintainability.\n\n### Review Time\n\nExpect review periods of 6 months to a year for integrating major new in-scope features. Our\npriority as previously stated is stability and quality, not adding features as quickly as possible.\nWhile you work with us to integrate your feature, we highly encourage you to maintain your own fork\nso you and others can use the feature immediately – and gain valuable implementation experience.\n</yakaai_skills>"}