[ADC-Ext 1.0.8] OID - Exchange Online IDs

Pretorian
Site Admin
Posts: 213
Joined: 21 Jul 2009, 10:21

Re: OID - Exchange Online IDs

Post by Pretorian » 03 Jun 2013, 20:15

I'd like a note on whether services are case sensitive. (I'd prefer case-insensitivity.)

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: OID - Exchange Online IDs

Post by poy » 03 Jun 2013, 20:44

Made services case-insensitive and rephrased the note about unlisted services to be more formal:
poy wrote:The purpose of the OID command is to allow users to exchange information about their accounts on various online services. The name of the command has been intentionally chosen to be similar to OpenID, although its spread is broader.

A new command is preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. It also allows for more flexibility: multiple profiles of the same type; multiple identification parameters.

Parameters of the OID command:
- Unnamed parameter in first position to designate the service this command is referring to. Known services are listed in the "Known OID services" document; they are matched case-insensitively. Implementers willing to use an unlisted service SHOULD let ADC managers know about it.
- Optional named parameters whose meanings depend on the service in question.

OID commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID information travelling through hubs. Hubs may request OID information from clients. Clients may request OID information from hubs.

The requesting party MUST send an OID command with a service parameter only (no optional parameter). The responding party MAY answer with an OID command containing that same service parameter, and relevant optional parameters.
The responding party MAY send multiple OID commands in response to one request.
The responding party MAY provide no information, usually indicating a refusal or inability to communicate it.
Any party MAY at any time send an OID response without any prior request.

The OID command is designed as a request/response scheme. OID parties are therefore not required to keep their OID information up-to-date.

Known services:
- DCBase: ID is the DCBase forum member numeric identifier.
- Facebook: ID is the public Facebook ID (that appears in a profile page's URL), NI (optional) is the friendly name.
- Google: EM is the Google email.
- LoL: SU is the League of Legends summoner name; SE is the server identifier, which MUST be one of "br", "eune", "euw", "kr", "na", "tr", "ru" that stand for, respectively, "Brazil", "EU Nordic & East", "EU West", "Korea", "North America", "Turkey", "Russia".
- MSLive: EM is the Microsoft Live email.
- PSN: ID is the PlayStation Network ID.
- Twitter: ID is the Twitter profile ID (that appears in a profile page's URL), NI (optional) is the nickname.
- Yahoo: EM is the Yahoo! email.

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: OID - Exchange Online IDs

Post by poy » 04 Jun 2013, 17:22

Changed a MUST to SHOULD in the LoL service (servers can change in the future):
poy wrote:The purpose of the OID command is to allow users to exchange information about their accounts on various online services. The name of the command has been intentionally chosen to be similar to OpenID, although its spread is broader.

A new command is preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. It also allows for more flexibility: multiple profiles of the same type; multiple identification parameters.

Parameters of the OID command:
- Unnamed parameter in first position to designate the service this command is referring to. Known services are listed in the "Known OID services" document; they are matched case-insensitively. Implementers willing to use an unlisted service SHOULD let ADC managers know about it.
- Optional named parameters whose meanings depend on the service in question.

OID commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID information travelling through hubs. Hubs may request OID information from clients. Clients may request OID information from hubs.

The requesting party MUST send an OID command with a service parameter only (no optional parameter). The responding party MAY answer with an OID command containing that same service parameter, and relevant optional parameters.
The responding party MAY send multiple OID commands in response to one request.
The responding party MAY provide no information, usually indicating a refusal or inability to communicate it.
Any party MAY at any time send an OID response without any prior request.

The OID command is designed as a request/response scheme. OID parties are therefore not required to keep their OID information up-to-date.

Known services:
- DCBase: ID is the DCBase forum member numeric identifier.
- Facebook: ID is the public Facebook ID (that appears in a profile page's URL), NI (optional) is the friendly name.
- Google: EM is the Google email.
- LoL: SU is the League of Legends summoner name; SE is the server identifier, which SHOULD be one of "br", "eune", "euw", "kr", "na", "tr", "ru" that stand for, respectively, "Brazil", "EU Nordic & East", "EU West", "Korea", "North America", "Turkey", "Russia".
- MSLive: EM is the Microsoft Live email.
- PSN: ID is the PlayStation Network ID.
- Twitter: ID is the Twitter profile ID (that appears in a profile page's URL), NI (optional) is the nickname.
- Yahoo: EM is the Yahoo! email.

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: OID - Exchange Online IDs

Post by poy » 08 Jun 2013, 11:23

Renamed OID to OIR and added a new OID command with the purpose of providing up-to-date INF-style information:
poy wrote:The purpose of the OID and OIR commands is to allow users to exchange information about their accounts on various online services. The OID name has been intentionally chosen to be similar to OpenID, although its spread is broader.

New commands are preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. They also allow for more flexibility: multiple profiles of the same type (OIR only); multiple identification parameters.

The OID command is similar to INF, guaranteeing up-to-date information, whereas OIR follows a request/response scheme. OIR parties are therefore not required to keep their OIR information up-to-date.

Parameters of the OID and OIR commands:
- Unnamed parameter in first position to designate the service this command is referring to. Known services are listed in the "Known OID/OIR services" document; they are matched case-insensitively. Implementers willing to use an unlisted service SHOULD let ADC managers know about it.
- Optional named parameters whose meanings depend on the service in question.

OID and OIR commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID/OIR information travelling through hubs. Both clients and hubs MAY provide each other with OID/OIR information.

OID specifics:
Any party that has sent OID information about itself SHOULD keep it up-to-date.
OID parties MAY provide no information, usually indicating a refusal or inability to communicate it.
Hubs SHOULD dispatch OID information they have received from clients to other clients, similary to INF information.

OIR specifics:
The requesting party MUST send an OIR command with a service parameter only (no optional parameter). The responding party MAY answer with an OIR command containing that same service parameter, and relevant optional parameters.
The responding party MAY send multiple OIR commands in response to one request.
The responding party MAY provide no information, usually indicating a refusal or inability to communicate it.
Any party MAY at any time send an OIR response without any prior request.

Known services:
- DCBase: ID is the DCBase forum member numeric identifier.
- Facebook: ID is the public Facebook ID (that appears in a profile page's URL), NI (optional) is the friendly name.
- Google: EM is the Google email.
- LoL: SU is the League of Legends summoner name; SE is the server identifier, which SHOULD be one of "br", "eune", "euw", "kr", "na", "tr", "ru" that stand for, respectively, "Brazil", "EU Nordic & East", "EU West", "Korea", "North America", "Turkey", "Russia".
- MSLive: EM is the Microsoft Live email.
- PSN: ID is the PlayStation Network ID.
- Twitter: ID is the Twitter profile ID (that appears in a profile page's URL), NI (optional) is the nickname.
- Yahoo: EM is the Yahoo! email.

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: OID - Exchange Online IDs

Post by poy » 09 Jun 2013, 21:27

Added ONID support for OID commands and adjusted related hub-side rules:
poy wrote:The purpose of the OID and OIR commands is to allow users to exchange information about their accounts on various online services. The OID name has been intentionally chosen to be similar to OpenID, although its spread is broader.

New commands are preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. They also allow for more flexibility: multiple profiles of the same type (OIR only); multiple identification parameters.

The OID command is similar to INF, guaranteeing up-to-date information, whereas OIR follows a request/response scheme. OIR parties are therefore not required to keep their OIR information up-to-date.

Parties supporting OID commands MUST advertise the ONID (ONline IDentification) support in the SU field of their INF.

Parameters of the OID and OIR commands:
- Unnamed parameter in first position to designate the service this command is referring to. Known services are listed in the "Known OID/OIR services" document; they are matched case-insensitively. Implementers willing to use an unlisted service SHOULD let ADC managers know about it.
- Optional named parameters whose meanings depend on the service in question.

OID and OIR commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID/OIR information travelling through hubs. Both clients and hubs MAY provide each other with OID/OIR information.

OID specifics:
Any party that has sent OID information about itself SHOULD keep it up-to-date.
OID parties MAY provide no information, usually indicating a refusal or inability to communicate it.
Hubs that advertise ONID support MUST dispatch OID information they have received from clients to new clients logging in, similary to INF information.
Clients MAY send OID commands to other clients on hubs that do not advertise ONID support.

OIR specifics:
The requesting party MUST send an OIR command with a service parameter only (no optional parameter). The responding party MAY answer with an OIR command containing that same service parameter, and relevant optional parameters.
The responding party MAY send multiple OIR commands in response to one request.
The responding party MAY provide no information, usually indicating a refusal or inability to communicate it.
Any party MAY at any time send an OIR response without any prior request.

Known services:
- DCBase: ID is the DCBase forum member numeric identifier.
- Facebook: ID is the public Facebook ID (that appears in a profile page's URL), NI (optional) is the friendly name.
- Google: EM is the Google email.
- LoL: SU is the League of Legends summoner name; SE is the server identifier, which SHOULD be one of "br", "eune", "euw", "kr", "na", "tr", "ru" that stand for, respectively, "Brazil", "EU Nordic & East", "EU West", "Korea", "North America", "Turkey", "Russia".
- MSLive: EM is the Microsoft Live email.
- PSN: ID is the PlayStation Network ID.
- Twitter: ID is the Twitter profile ID (that appears in a profile page's URL), NI (optional) is the nickname.
- Yahoo: EM is the Yahoo! email.

Pretorian
Site Admin
Posts: 213
Joined: 21 Jul 2009, 10:21

Re: OID - Exchange Online IDs

Post by Pretorian » 17 Jun 2013, 17:20

This is now in upcoming ADC-Ext 1.0.8. See ADC-ONIDServices.txt for the services.

Locked

Who is online

Users browsing this forum: No registered users and 0 guests