Skip to content

Commit 4978c92

Browse files
melissahendersonJoblersTuneAnca2022
authored
docs: adding es-translated pages (#678)
* docs: adding es-translated pages * docs: fix build errors * docs: more build fixes I suspect the issues are due to a combo of "it" not liking lists beginning with the linkout component and Blair's change to prettier yesterday * Update docs/src/content/docs/es/overview/getting-started.mdx Co-authored-by: Sarah Jones <[email protected]> * Update docs/src/content/docs/es/identity/idp.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/content/docs/es/guides/make-onetime-payment.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/content/docs/es/identity/client-keys.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/content/docs/es/identity/client-keys.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/content/docs/es/concepts/payments.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/content/docs/es/identity/client-keys.mdx Co-authored-by: Anca Matei <[email protected]> * Update docs/src/partials/es/before-you-begin.mdx Co-authored-by: Sarah Jones <[email protected]> --------- Co-authored-by: Sarah Jones <[email protected]> Co-authored-by: Anca Matei <[email protected]>
1 parent 0c957fb commit 4978c92

29 files changed

+2084
-146
lines changed

‎docs/astro.config.mjs‎

Lines changed: 32 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -35,11 +35,14 @@ export default defineConfig({
3535
// defaultLocale: 'root',
3636
locales: {
3737
root: {
38+
// English docs in `src/content/docs`
3839
label: 'English',
3940
lang: 'en'
4041
},
4142
es: {
42-
label: 'Español'
43+
// Spanish docs in `src/content/docs/es`
44+
label: 'Español',
45+
lang: 'es'
4346
}
4447
},
4548
expressiveCode: {
@@ -84,56 +87,75 @@ export default defineConfig({
8487
sidebar: [
8588
{
8689
label: 'Overview',
90+
translations: { es: 'Descripción general' },
8791
items: [
88-
{ label: 'Getting started', link: '/overview/getting-started/' },
92+
{
93+
label: 'Getting started',
94+
translations: { es: 'Cómo empezar' },
95+
link: '/overview/getting-started/'
96+
},
8997
{
9098
label: 'Concepts',
99+
translations: { es: 'Conceptos' },
91100
collapsed: false,
92101
items: [
93102
{
94103
label: 'Wallet addresses',
104+
translations: { es: 'Direcciones de billetera' },
95105
link: '/concepts/wallet-addresses/'
96106
},
97107
{
98108
label: 'Resources',
109+
translations: { es: 'Recursos' },
99110
link: '/concepts/resources/'
100111
},
101112
{
102113
label: 'Authorization',
114+
translations: { es: 'Autorización' },
103115
link: '/concepts/auth/'
104116
},
105117
{
106118
label: 'Payment methods',
119+
translations: { es: 'Métodos de pago' },
107120
link: '/concepts/payments/'
108121
},
109122
{
110123
label: 'Open Payments flow',
124+
translations: { es: 'Flujo de Open Payments' },
111125
link: '/concepts/op-flow/'
112126
}
113127
]
114128
},
115129
{
116130
label: 'Identity and access management',
131+
translations: { es: 'Gestión de la identidad y el acceso' },
117132
collapsed: true,
118133
items: [
119134
{
120135
label: 'Grant negotiation and authorization',
136+
translations: {
137+
es: 'Negociación y autorización de las concesiones'
138+
},
121139
link: '/identity/grants/'
122140
},
123141
{
124142
label: 'Identity providers',
143+
translations: { es: 'Proveedores de identidad' },
125144
link: '/identity/idp/'
126145
},
127146
{
128147
label: 'Client keys',
148+
translations: { es: 'Claves de cliente' },
129149
link: '/identity/client-keys/'
130150
},
131151
{
132152
label: 'HTTP signatures',
153+
translations: { es: 'Firmas de mensajes HTTP' },
133154
link: '/identity/http-signatures/'
134155
},
135156
{
136157
label: 'Hash verification',
158+
translations: { es: 'Verificación de hash' },
137159
link: '/identity/hash-verification/'
138160
}
139161
]
@@ -260,28 +282,36 @@ export default defineConfig({
260282
},
261283
{
262284
label: 'Guides',
285+
translations: { es: 'Guías' },
263286
collapsed: true,
264287
items: [
265288
{
266289
label: 'Make a one-time payment',
290+
translations: { es: 'Cómo efectuar un pago único' },
267291
link: '/guides/make-onetime-payment/'
268292
},
269293
{
270294
label: 'Make recurring payments',
295+
translations: { es: 'Realizar pagos recurrentes' },
271296
link: '/guides/make-recurring-payments/'
272297
},
273298
{
274299
label: 'Split an incoming payment',
300+
translations: { es: 'Dividir un pago entrante' },
275301
link: '/guides/split-payments/'
276302
},
277303
{
278304
label: 'Get an outgoing payment grant for future payments',
305+
translations: {
306+
es: 'Obtener una concesión de pago saliente para pagos futuros'
307+
},
279308
link: '/guides/outgoing-grant-future-payments/'
280309
}
281310
]
282311
},
283312
{
284313
label: 'Resources',
314+
translations: { es: 'Recursos' },
285315
collapsed: true,
286316
items: [
287317
{

‎docs/src/content/docs/es/concepts/auth.mdx‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: Autorización
3+
parent: Concepts
4+
---
5+
6+
import { LinkOut, Tooltip } from '@interledger/docs-design-system'
7+
8+
:::tip[Resumen]
9+
La autorización en Open Payments (estándar de pagos abiertos) se refiere al proceso mediante el cual un cliente obtiene el permiso de un propietario de recursos para acceder a los recursos protegidos y operar en ellos.
10+
:::
11+
12+
Open Payments aprovecha el Protocolo de Negociación y Autorización de Concesiones <LinkOut href='https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol'>(Grant Negotiation and Authorization Protocol, GNAP)</LinkOut> como el mecanismo mediante el cual un programa de software, conocido como “instancia de cliente” (o simplemente “cliente”), recibe la delegación de autorización para utilizar las interfaces de programación de aplicaciones (application programming interfaces, API) de Open Payments para interactuar con las cuentas admitidas.
13+
14+
## Servidor de autorización
15+
16+
El servidor de autorización concede permisos para que un cliente acceda a las API de Open Payments y los recursos de `incoming-payment`, `quote` y `outgoing-payment`. Para ello, emite tókenes de acceso que representan un conjunto de derechos de acceso o atributos concedidos al cliente. Con los tókenes de acceso adecuados, el cliente puede ejecutar las operaciones permitidas, como crear pagos entrantes y salientes, en nombre del propietario del recurso (resource owner, RO).
17+
18+
### Relación entre las concesiones y los tókenes de acceso
19+
20+
Una **concesión** es una autorización que emite el RO para permitir que un cliente acceda a recursos específicos. La concesión de autorización especifica el tipo de acciones que el cliente puede efectuar. Puede requerir la interacción del usuario y está sujeta al consentimiento del RO. El servidor de autorización valida la concesión cada vez que el cliente utiliza su token de acceso.
21+
22+
Un **token de acceso** se emite luego de que el servidor de autorización aprueba una solicitud de concesión. Este token funciona como una credencial que el cliente utiliza para su propia autenticación a la hora de emitir solicitudes de acceso a recursos protegidos. El token de acceso contiene información sobre los permisos concedidos, lo que incluye las acciones específicas que el cliente puede realizar y los recursos a los que puede acceder.
23+
24+
## Tipos de concesiones
25+
26+
En esta sección, se detallan los diferentes tipos de concesiones de autorización que los clientes pueden solicitar en el entorno de Open Payments. Aunque el flujo suele comenzar con una concesión para un pago entrante, existen situaciones en las que otros tipos de concesiones pueden solicitarse primero.
27+
28+
### Pago entrante
29+
30+
Por lo general, para iniciar el flujo de Open Payments, el cliente solicita una concesión de autorización para un pago entrante al servidor de autorización que corresponde al _destinatario_. Sin embargo, existen situaciones en las que el cliente solicita una concesión de autorización para un pago saliente primero, como en el caso de Web Monetization (estándar de monetización web).
31+
32+
El cliente puede solicitar una sola concesión de autorización para crear varios pagos entrantes destinados a distintas cuentas compatibles con Open Payments, siempre que todas las cuentas pertenezcan a la misma <Tooltip content="Entidad que administra la cuenta" client: load><span>ASE</span></Tooltip>.
33+
34+
Por defecto, las concesiones de autorización para pagos entrantes no son interactivas; esto significa que no se requiere la interacción de una persona (por lo general, el usuario del cliente) para que el servidor de autorización emita un token de acceso.
35+
36+
### Cotización
37+
38+
Una vez que el cliente recibe una concesión de autorización para un pago entrante y se crea un recurso de pago entrante en la cuenta del destinatario, el cliente solicita la concesión de autorización para una cotización al servidor de autorización que corresponde al _remitente_. El cliente puede solicitar una sola concesión de autorización para crear varias cotizaciones destinadas a distintas cuentas compatibles con Open Payments, siempre que todas las cuentas pertenezcan a la misma <Tooltip content="Entidad que administra la cuenta" client: load><span>ASE</span></Tooltip>.
39+
40+
Por defecto, las concesiones de autorización para cotizaciones no son interactivas; esto significa que no se requiere la interacción de una persona (por lo general, el usuario del cliente) para que el servidor de autorización emita un token de acceso.
41+
42+
### Pago saliente
43+
44+
Una vez que el cliente avanzó en las secciones de pagos entrantes y cotizaciones del flujo de Open Payments, está listo para solicitar una concesión de autorización para un pago saliente al servidor de autorización que corresponde al _remitente_.
45+
46+
En Open Payments, se exige que las solicitudes de concesiones de autorización para los pagos salientes sean interactivas. Esto significa que la interacción explícita de una persona (por lo general, el usuario del cliente) es un paso obligatorio en el proceso de delegación.
47+
48+
Luego de una interacción correcta, el cliente debe emitir una [solicitud de continuación de la concesión de autorización](/apis/auth-server/operations/post-continue), para que el servidor de autorización sepa que debe emitir un token de acceso.
49+
50+
## Más información sobre la autorización
51+
52+
Para profundizar en los temas relacionados con la autorización, por ejemplo, el Protocolo de Negociación y Autorización de Concesiones (Grant Negotiation and Authorization Protocol, GNAP) y la solicitud de concesiones de autorización, consulte la sección [Negociación y autorización de concesiones](/es/identity/grants) y otras páginas incluidas en **Gestión de la identidad y el acceso**.

0 commit comments

Comments
 (0)