Global account numbers (entity IDs) are redundant? Well, that means that business entities must use their partners' unique local account ID when they send for instance a purchase order. It also means that you must keep records of all your business parties local ID of _your_ entity. Having global account numbers you can safely ignore your business partners' account IDs of your business except when you get something in return like an invoice. In those situations it is nice to have the partner's local ID of you, as call- centers usually look on local IDs which are the index in the databases as well.
Only in a relying party PK-model global account numbers become redudant. In such systems you not only need to have the unique local ID but also unique private keys depending on the verifiers policy. Further advantages with global account IDs is that TTPs can provide services like credit status. This is one of the reasons D U N S is often required in the states. But are D U N S globally unique? In fact they are, it is just that you currently have to _know_ that it is a D&B-assigned number and not some other registry. The described IETF-draft in preparation is designed to solve this by adding a universal "account authority" solution. My conclusion is that the mechanisms used in the financial industry does not perfectly match the needs of non-payment "transactions". For list-usage reasons I will though refrain from further discussions on this particular subject. /ar ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Anders Rundgren" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, June 25, 2003 16:53 Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda) this is grossly confusing, dynamic, realtime paradigm with the static, stale, certificate offline paradigm. the credit/debit 8383 online network has worked with multiple "handles" for 30 years or so. You can have dozen of cards ... and each card can actually have one or more account numbers .... you do a transaction and the handle/account number gets filled in appropriately in real time. RADIUS works for corporate accounts and all the ISP accounts. I have multiple accounts and all the appropriate handle/account information is filled in dynamically, its gets correctly routed and processed w/o anybody worrying that it can't work unless I have the same username on my corporate login as well as every last one of my multiple ISP accounts. The problem with static, stale, certificates that were manufactored at some point way in the past with no real good idea what future purposes that the certificate might be used for. The problem isn't so much that the same certificate wants to be used with huge number of different relying parties .... it was at the time that the certificate was manufactored that a one and only one static, stale account number/handle had to be selected. The issue in the certificate business ... is that certification is somewhat expensive .... and to work with static, stale information ... that can be globally used .... you have to convert the whole-world to a single handle/account number .... or have multiple relying-party-only certificates, one for each environment. There are at least tens of thousands of financial institutions all issuing account numbers and all getting routed accordingly. It turns out the account numbers are partly routing code and partly individual unique Extended outside of the financial infrastructure .... to all the ISPs in the world .... frequently you have to configure your TCP/IP client to have a prefix like: XXXX/username this in part directs the routers by 3rd party POP operators to deal with the appropriate RADIUS server for the authentication information. So not only does it work for 99.999999999 percent of the online financial trransactions ... but it also works for 99.9999999 percent of the people accessing the internet around the world. The issue of a globally unique identifier is not a requirement of an online authentication infrastructure. The issue of a globally unique identifier is a requirement for stale, static certificate paradigm with regards to not needing to issue a unique relying-party-only certificate (for every environment) and allowing a single stale, static certificate to used in multiple environments. Now, for an online environment ... there is context in the type of authorization and the type of message. Now, if i was inventing a single transaction protocol and message interface ... where the same exact message format was used for all contexts .... i.e. a x9.59/iso8583 financial message had the same format as a radius connect to the internet message; then i could hypothosize overloading the entity handle with type of message, type of transaction, type of entity, routing information, and personal information. That way ... I could use the same account number and same message format and same network interface for logging in via RADIUS as I used for performing a credit operation. The network interface could figure out what i intended to do. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm [EMAIL PROTECTED] on 6/25/2003 12:53 am wrote: A problem in this area is the all-over-the-map representation of entities when you go outside of the original (bank) account number. Well, even these show some variances, don't they? So when Lynn claims that the account number is redudant in for example certificates as it is already in the transaction payload, this is by no means a universal truth if you extend transactions outside of the financial area. In order to actually eliminate certficates or just be able to match the "account number" (the entity's identity) as expressed in a certificate with transaction payloads we need to have a universal naming method. Currently we don't have that. Even major B2B efforts like ebXML still have not solved this in an non-ambigous way. I.e, it is hard for many people to leave (or rather reduce the importance of) the attribute style of describing an entity's identity like: Locality, Common Name, Phone number etc. That hardly any business system in the world uses anything but a customer ID (account number) is still not generally recognized. I'm am plotting with an Internet Draft which defines a universal globally unique "account number" consisting of a 2-dimensional structure like the following: NameSpace : LocalID NameSpace is a Universal Resource Identifier (URI) that identifies the owner of the "namespace". Samples: urn:visa:cc http://xmlns.ibm.com/employees LocalID is just a string that is guaranteed to uniquely identify the entity in the associated NameSpace. Samples matching the previous sample: 46566777555556766 35467 For X.509 certificates there is a specific extension in preparation that enables the inclusion of such account numbers without disrupting the current use of Subject DN: ____ / \ | CA | Naming Domain: http://sample-registry.org/members \____/ PI Attribute: serialNumber / \ / \ / _\__ | / \ | | EE | Subject: CN=John Doe, serialNumber=43155, C=US | \____/ _|__ / \ | EE | Subject: CN=Marion Anderson, serialNumber=43566, C=US \____/ That is, Marion's ID could using PI be expressed like: "http://sample-registry.org/members"; : "43566" As an option the permanent identifier descriptor MAY declare a separate PI naming domain.
