Resources
Identity Use Cases & Scenarios.
FIDIS Deliverables.
Identity of Identity.
Interoperability.
Profiling.
Forensic Implications.
HighTechID.
D3.1: Overview on IMS.
D3.2: A study on PKI and biometrics.
D3.3: Study on Mobile Identity Management.
D3.5: Workshop on ID-Documents.
D3.6: Study on ID Documents.
D3.7: A Structured Collection on RFID Literature.
D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication.
D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management.
D3.10: Biometrics in identity management.
D3.11: Report on the Maintenance of the IMS Database.
D3.15: Report on the Maintenance of the ISM Database.
D3.17: Identity Management Systems – recent developments.
D12.1: Integrated Workshop on Emerging AmI Technologies.
D12.2: Study on Emerging AmI Technologies.
D12.3: A Holistic Privacy Framework for RFID Applications.
D12.4: Integrated Workshop on Emerging AmI.
D12.5: Use cases and scenarios of emerging technologies.
D12.6: A Study on ICT Implants.
D12.7: Identity-related Crime in Europe – Big Problem or Big Hype?.
D12.10: Normality Mining: Results from a Tracking Study.
Privacy and legal-social content.
Mobility and Identity.
Other.
IDIS Journal.
FIDIS Interactive.
Press & Events.
In-House Journal.
Booklets
Identity in a Networked World.
Identity R/Evolution.
Spamgourmet feedback
Spamgourmet Identity Management System
Verification of data – Instructions
Please indicate with a Yes/No in the respective field of the following table the correctness / completeness of the data held in our database. If you find that the data is not correct and/or complete, please proceed with making the appropriate corrections / additions by appropriately filling in the next field (“Correction / Completion”).
For a description / definition of each field, you can refer at Table B.
TABLE A – Verification of Data | ||||
Data held in database | Yes/No | Correction / Completion | ||
Evaluation of IMS | ||||
Evaluator: | Christian Krause | Yes |
| |
Organisation: | ICCP | Yes |
| |
Date of evaluation: | 14-Oct-2005 | Yes |
| |
Identification of IMS | ||||
Sources of information: | Yes |
| ||
Version: |
| No | 1.22 | |
Manufacturer: | diverse | Yes |
| |
Nature: | private | Yes |
| |
Country: | n.a. | No | USA | |
Regions: | Global | Yes |
| |
Language: | ENGLISH | No | Various (15 total for user interface) | |
State: | Available | Yes |
| |
Open/Closed: | Open IMS: the identities work with several systems or applications. | Yes |
| |
Platform & Environment | ||||
Requirements: | Browser, E-Mail client | Yes |
| |
Number of users: | >100.000 users. Server-software is OpenSource, but no installation-base apart from the developer’s service is published. | Yes | (there are other installations, but not published) | |
Standards: | none | No | SMTP (but I may be misinterpreting this question – if it’s referring to privacy standards, then yes, it’s correct) | |
Description of Server - Side components: | software is written entirely in PERL | Yes |
| |
Description of methods: | An account is created wherin the user’s mail-address is being stored. After registration, users can generate one-time addresses connected to their account. Mails sent to this address are forwarded only for a specified period, e.g. four times. | No | Text is correct, but I would substitute the phrase “limited use” for the phrase “one-time” | |
Descriptor of Client - | Browser to register with the service, E-Mail client to receive one-time mail | No | Same comment as immediately above – substitute “limited use” for “one-time” | |
Seals: | No | Yes |
| |
Which seal: |
| Yes |
| |
Third party: | no | Yes |
| |
Which third party: |
| Yes |
| |
Features: | The service hides the original mail-address. Since the specific username appears in every generated one-time address, there is only pseudonymity given. | Yes |
| |
Screenshot picture: | Yes | (will have to trust you on this one) | ||
Flowchart: | Yes |
| ||
Cost | ||||
Price: | 0 | Yes |
| |
Comment to the Cost: |
|
|
| |
Type & Class of IMS | ||||
Type of IMS: | Type 3: IMS for user-controlled context-dependent role and pseudonym management. | Yes |
| |
Class of IMS: | Class 2: Systems/applications with another core functionality. | Yes |
| |
Functionality: | Spamgourmet’s main purpose is avoiding spam. Generating multiple addresses is used as an instrument. | Yes |
| |
Suggestions: | There are two ways spamgourmet can be operated: 1. Make up addresses like "someword.x.user@spamgourmet.com", where "someword" is a randomstring and x is the number of mails that shall be received. 2. The above structure can be combined with "watchwords". These are user-generated and stored in the service. Only mails to addresses containing one ore more watchwords are forwarded. This makes it harder for attackers to construct a valid address from scratch. The service allows to create arbitrary mail-addresses and thus avoid spam, although linkability of these created addresses is not averted due to identical unique strings (the username) in all generated addresses. | No | Text is correct, but there are other features, including the ability to send email as if it came from a disposable address |
15 / 15 |